Security

What Observer does today to keep your data safe, what we do not yet do, and how to report a security issue. Last updated 2026-07-06.

Effective date: 2026-05-24 Last updated: 2026-07-06

This page describes what Observer does today to protect customer data. We try to be specific. If we have not done something, we say so rather than implying we have. The Service is provided "as is" (see the Terms of Service), and an honest description of what we actually do is part of how we make that posture defensible.

If you are evaluating Observer for a procurement process and need information beyond what is on this page, write to [email protected].

If you have discovered a security issue, write to [email protected]. See section "Responsible disclosure" below.

At a glance

The rest of this page elaborates each row.

Hosting and data residency

The primary database, application servers, and backup object storage are hosted with Hetzner Online GmbH in Germany. Hetzner is the controller of the underlying physical infrastructure and operates inside the European Economic Area.

A disaster-recovery replica of the production Postgres database is held with Oracle Cloud Infrastructure in the United Kingdom (Oracle Corporation UK Limited, London / Newport regions). The replica carries the same categories of personal data as the primary so that the Service can be restored from a different jurisdiction if the primary region becomes unavailable. EU-to-UK transfer of this replica is covered by the EU adequacy decision for the United Kingdom (Commission Implementing Decision (EU) 2021/1772); UK Personal Data does not leave the United Kingdom.

We do not replicate Customer Data outside the EEA and the United Kingdom. Where a specific subprocessor (see Subprocessors) is located outside the EEA / UK, those transfers are covered by the 2021 Standard Contractual Clauses and, where relevant, the UK International Data Transfer Addendum.

Encryption in transit

All connections to use.observer, docs.use.observer, and any customer status page served on a use.observer subdomain are served over TLS. TLS is terminated at our content delivery network provider, Cloudflare, which provisions Universal SSL certificates and proxies traffic to our origin servers. Custom domains attached by customers to status pages also receive Cloudflare-managed TLS via Cloudflare for SaaS.

The Observer Agent posts to Observer Cloud over HTTPS.

Encryption at rest

Backups. Database backups, write-ahead log segments, and all bucket contents are encrypted in transit to and at rest in object storage by the hosting provider. The provider's storage encryption applies to all bucket data regardless of bucket configuration.

Live database volumes. Live database volume encryption is being enabled. We will update this section when the migration is complete. We have chosen not to claim full live-volume encryption-at-rest until that work is in production.

Authentication and access control

User authentication is handled by Clerk. Sessions are managed by Clerk, with the session cookie set on the use.observer domain. We do not run our own credential store and we never see customer passwords.

API access uses bearer tokens that customers create in the dashboard. Token values are generated from 32 bytes of cryptographically random data and are shown to the customer once. Only a SHA-256 hash is persisted in the database. We are physically incapable of returning a forgotten token; the customer must create a new one.

The Observer Agent authenticates the same way. Agent keys are generated from cryptographically random data. The raw key is shown to the customer once at creation and is not retrievable thereafter. Customers can rotate agent keys from the dashboard at any time, with an optional grace period during which the old key still authenticates.

Tenancy isolation

Observer is multi-tenant. Tenancy is enforced on every request: middleware verifies organisation membership before any data access, and every database read and write is scoped to the requesting organisation's identifier. Isolation is enforced at the application layer.

That boundary is continuously verified. An automated test suite attempts cross-tenant reads, writes, updates, and deletes on every build, and the build fails if any path returns or modifies another tenant's data. Detailed architecture questions from procurement or security teams are answered under NDA via [email protected].

Audit logging

Administrative actions on the Service (creating or modifying agents, pages, metrics, customers, webhooks, API keys; rotating credentials; changing access settings; subscribing or unsubscribing from a plan; and similar) write a row to an append-only audit log. The log captures:

• the organisation,
• the user who acted (or a system / agent actor where applicable),
• a stable verb identifying the action,
• the target resource type and identifier,
• a small structured metadata payload,
• the client IP address,
• the User-Agent string,
• the timestamp.

No update or delete operations against the audit log are emitted by the application. Entries older than 60 days are removed by a scheduled job.

Outbound webhooks

Outbound webhooks from Observer to a customer's endpoint are signed with HMAC-SHA-256. The signed material is the concatenation <timestamp>.<rawBody>, where <timestamp> is the millisecond Unix time when we built the request. The signature is sent as X-Observer-Signature: sha256=<hex> and the timestamp is sent as X-Observer-Timestamp: <milliseconds>. Receivers should verify the signature and reject deliveries whose timestamp falls outside a tolerance window of their choosing (we recommend five minutes).

For backwards compatibility with the previous signing scheme, we also send X-Observer-Signature-Legacy, an HMAC over the raw body only. Customers should migrate to the timestamp-prefixed signature.

Failed deliveries are retried with backoff up to three attempts. Deliveries that still fail are retained and can be redelivered once the receiving endpoint recovers.

Rate limiting and abuse controls

Observer applies rate limits at the authentication, API, and webhook layers, with budgets that vary by endpoint.

Outbound webhook subscriptions have per-endpoint daily and concurrency caps to prevent run-away outbound traffic to customer endpoints.

Backups and recovery

The primary database is backed up daily using our managed Postgres backup tooling. Backups are written to S3-compatible object storage at the same hosting provider as the primary database, inside the EEA.

Write-ahead log archiving is enabled, which is what makes point-in-time recovery possible (a daily snapshot alone is not). We are working through the retention configuration with a target recovery window of 14 days. We will update this section when the retention configuration is fixed at the target window.

Probes and monitoring features

Observer's monitoring features include:

• Prometheus probes (PromQL evaluated inside the customer's network by the Agent);
• HTTP probes (status code + optional body match, redirects followed, optional TLS verification toggle, optional mutual TLS using certificate material referenced by environment-variable name — the certificate and key never leave the Agent host);
• TCP probes (connect-and-close timing);
• DNS probes (A / AAAA / CNAME / MX / TXT / NS / SRV / CAA / PTR resolution, with custom resolver);
• TLS certificate expiry probes (days until expiry);
• ICMP probes (latency / packet loss / reachability, via the system ping binary);
• gRPC health probes (standard gRPC Health Checking Protocol only; no arbitrary method invocation);
• WebSocket probes (handshake and round-trip timing);
• Database probes (Postgres, MySQL, Redis, MongoDB — read-only queries only, enforced by a SELECT-only parser or command allowlist; the connection string is referenced by environment-variable name on the Agent host and is never transmitted to or stored by Observer Cloud);
• OTLP metrics receiver (push-mode listener on the Agent, loopback-only by default, bearer-token required for non-loopback binds);
• CloudWatch, Loki, and Elasticsearch readers (credentials sourced from the Agent's own environment; never stored in Observer Cloud);
• Custom probes (customer-registered code running in the Agent, within the customer's own trust boundary).

A consistent design rule applies across all of these: secrets stay on the Agent host. Database connection strings, client certificates, bearer tokens, and cloud credentials are referenced by environment-variable name in the probe configuration; Observer Cloud stores only the name, never the value.

The Agent computes status verdicts locally and pushes only the verdict to Observer Cloud. PromQL query strings and probe configuration content are not transmitted on every push; they are configured separately. We hash query strings before they are written to operational logs.

Observability of the Service itself

We expose Prometheus metrics about the Service to a private endpoint, protected by a bearer token. These metrics describe the Service's behaviour and do not contain customer data.

Compliance posture

Observer holds no third-party security certifications (SOC 2, ISO 27001, HIPAA, PCI DSS). We do not collect or store card data. We do not provide a service-level credit regime; the Service is "as is" as set out in the Terms of Service. Specific compliance details for procurement evaluations are available on request to [email protected].

Responsible disclosure

If you believe you have found a security issue in Observer:

1. Write to [email protected]. Encrypt with PGP if you prefer; key fingerprint available on request.
2. Give us a reasonable window to fix it. We will acknowledge within three working days and aim to triage within five.
3. Do not publish details before we have had a chance to fix it. Standard responsible-disclosure practice.
4. Do not exfiltrate data, degrade the Service, or affect other customers' data while researching. Test against your own account.

We do not yet operate a paid bug bounty programme. We will credit researchers on request.

Our security.txt is available at the standard RFC 9116 path.

Subprocessors

The full subprocessor list, including the transfer mechanism for each, is at Subprocessors. The Data Processing Agreement sets out the contractual security baseline that flows down to each subprocessor.

Contact

• General security questions: [email protected]
• Disclosure: [email protected]