Security

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

A continuously replicated copy of the production database is kept ready, so the Service can be brought back from it if the primary environment fails.

The production database, its replicated copy, and its backups are held in the European Economic Area and the United Kingdom. Some subprocessors process the data they handle elsewhere, including in the United States. Our subprocessors, where each one processes data, and the transfer mechanism that applies are listed on the Subprocessors page. Where a subprocessor is located outside the EEA and the UK, transfers are covered by the safeguards shown there for that subprocessor.

Encryption in transit

All connections to use.observer, docs.use.observer, and customer status pages (on use.observer subdomains or on custom domains) are served over TLS.

The Observer Agent connects to Observer Cloud over HTTPS.

use.observer and its subdomains send HTTP Strict Transport Security headers, so browsers refuse to connect to them over plain HTTP.

Encryption at rest

Backups. Database backups and archived write-ahead logs are encrypted at rest in object storage.

Integration credentials. Credentials you store for alerting integrations (webhook URLs, routing keys, API tokens, signing secrets) are encrypted with AES-GCM before they are written to the database, and are shown masked in the dashboard.

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. We cannot return a forgotten token; the customer must create a new one.

The Observer Agent authenticates the same way: agent keys are generated from 32 bytes of cryptographically random data, shown once at creation, and stored only as a SHA-256 hash. Customers can rotate an agent key from the dashboard at any time, either keeping the old key valid for a 24-hour grace period or revoking it immediately.

Access to production systems is limited to authorised administrators bound by confidentiality obligations.

Private status pages

A status page can be public or restricted. Restricted pages support a password (stored only as a salted scrypt hash), signed access links, an IP allowlist, or sign-in with Google, Microsoft, or your own identity provider checked against an allowlist of email addresses or domains. Access cookies are HTTP-only, signed, and short-lived (see the Cookie Policy). Removing someone from a sign-in allowlist revokes their access on their next request.

Tenancy isolation

Observer is multi-tenant. Every request is checked for organisation membership before any data access, and every database read and write is scoped to the requesting organisation. Isolation is enforced in 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, integrations, API keys; rotating credentials; changing access settings; changing a plan; and similar) are recorded in an audit log. Each entry captures:

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

The audit log is append-only. The Service provides no way to edit audit entries, and the database itself refuses any change to or deletion of an existing entry. Entries leave the log only when they reach the end of the 90-day retention period or when the organisation they belong to is deleted. When a user's account is erased, their entries stay in the log with the reference to that user removed.

Outbound webhooks

Webhooks that status page subscribers register are always signed with HMAC-SHA-256, using a per-subscription secret shown to the subscriber once. Webhooks you configure for alerting are signed the same way when you set a secret. The signed material is <timestamp>.<rawBody>, where <timestamp> is the Unix time in milliseconds when we built the request. The signature is sent as X-Observer-Signature: sha256=<hex> and the timestamp 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.

Before each delivery the destination is re-checked, and requests to private, loopback, and cloud-metadata addresses are refused. Failed deliveries are retried automatically. Deliveries that still fail are kept and can be redelivered once the receiving endpoint recovers.

Rate limiting and abuse controls

The Service is protected by denial-of-service mitigations. Observer applies its own rate limits to the public API, Agent ingestion, and public status pages, with budgets that vary by endpoint and plan. Sign-in is protected by Clerk's own controls.

Outbound webhook endpoints can be given a daily delivery cap to prevent run-away traffic to customer endpoints.

Backups and recovery

Full backups of the production database are taken daily, and the database's write-ahead log is archived continuously. Together they allow point-in-time recovery to a chosen moment, not only to the last daily backup, within a retention period that is currently up to 30 days. Backups are encrypted at rest and are stored separately from the primary environment, so a failure of the primary does not take the backups with it. We have tested restoring the full database from these backups.

Signed evidence

If you opt in, each status change is signed with Ed25519, hash-chained to the previous one, and anchored through OpenTimestamps, so anyone can check that the history has not been altered since it was signed. Signed SLA statements and evidence exports use the same signing. A signature shows a record has not been changed; it does not independently verify the data your Agents reported.

Support requests

When you contact support from the console, you choose what to attach. Browser logs and network summaries are scrubbed of keys and tokens before they leave your browser, screen recordings mask form inputs, and screenshots and recordings are stored privately and deleted automatically after 60 days.

What the Agent sends, and what stays on your host

The Observer Agent runs inside your network and only makes outbound connections to Observer Cloud. Nothing in your network has to accept a connection from us.

• What the Agent sends. For each metric: the reading (a single number), the status verdict the Agent computed, a timestamp, and a reason code when no data was available. It also sends a heartbeat about itself every 30 seconds: agent version and build, uptime, the host name, queue depth, the source types in use, and the names of any custom probes you registered. Agents before version 1.7.0 also send each custom probe's description; Observer discards it and does not store it. Diagnostic logs stay on the host unless you turn on log forwarding (off by default); PromQL in those logs is reduced to a hash. When you browse CloudWatch metrics in the dashboard, the Agent lists them with the host's credentials and returns metric names and dimensions, no values.
• What Observer Cloud holds. The configuration you create in the dashboard: metric definitions, queries, thresholds, probe targets, and the readings and verdicts the Agent reports. The Agent fetches its configuration from Observer Cloud.
• What stays on your host. Secrets. Database connection strings, client certificates and keys, and access tokens for log and search backends are referenced in the probe configuration by environment-variable name and resolved on the Agent host; Observer Cloud stores only the name. Secret HTTP and WebSocket headers can be referenced the same way. Cloud provider credentials come from the host's own environment. Raw query results (rows, log lines, full series) also stay on the host; a query sends back only the number it extracted.

Database probes accept read-only queries only, checked by the Agent before they run; we still recommend connecting with a read-only database role. The Agent's OpenTelemetry receiver listens on loopback by default and requires a bearer token before it will listen on any other address. The Agent is open source, so you can read every line that runs in your network.

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]. If you need to send sensitive details, say so and we will agree a secure way to receive them.
2. Give us a reasonable window to fix it. We aim to acknowledge and triage reports promptly.
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]