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-05-24.

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

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. Every customer's data lives in the same database, on the same tables, and is isolated by an organisation identifier that is forced onto every read and every write at the application layer.

We do not use PostgreSQL row-level security. This is a deliberate choice: pooled database connections run as the same database role for every request, and enforcing tenancy at the database role layer requires per-request session variables that add round-trip cost we do not believe is justified for our threat model. The tenancy boundary is enforced at the application layer through middleware that verifies organisation membership before every request and through query wrappers that inject the organisation identifier into every database operation.

We run automated tests that try to perform cross-tenant reads, writes, updates, and deletes against the same application layer. The tests fail the build if any path returns or modifies a row belonging to another tenant.

This design accepts the risk that an application bug bypassing the application layer could leak data. In return, it removes per-query overhead, allows us to use a pooled connection, and keeps queries inspectable in the query layer. We consider this a fair trade-off given the alternative, but customers should be aware of it.

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 IP address as reported by the ingress controller's last X-Forwarded-For hop,
• the User-Agent string,
• the timestamp.

No update or delete operations against the audit log are emitted by the application. Old entries are removed by a scheduled job that runs every six hours and deletes rows older than 60 days.

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. After that they are moved to a dead-letter queue that operators can replay manually from the dashboard.

Rate limiting and abuse controls

Observer applies rate limits at the authentication, API, and webhook layers. Rate limits use sliding-window counters stored in the database; the budgets vary by endpoint. Bucket cleanup runs in the database every five minutes.

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, with redirects followed and an optional TLS verification toggle);
• 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).

The following are documented in the configuration system but the Agent runtime is not yet wired up: ICMP, gRPC, WebSocket, mTLS HTTP, and database probes. The configuration form will show these as planned / not yet shipped.

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]