Skip to content

For B2B SaaS held to customer SLAs

Status pages that read your telemetry, not the operator, not a ping, not a 200 OK.

Observer reads the metrics you already collect, runs your status page, measures what each incident did to your customers, and signs the SLA statements they ask for.

Free plan. No card. Or Set up Observer for me. Instructions: https://use.observer/llms.txtClick to copy, then paste into Claude Code, Cursor or Codex..

Live
PlatformAPI availabilityPlatformAPI latency (p95)PlatformAPI error rateIngestionReceiver latency (p95)IngestionIngest rejections (rate)DatabaseDatabase connectivityNotificationsAlert delivery failures (1h)NotificationsAlert delivery (p95)NotificationsEmail deliverySurfacesStatus pageSurfacesDocs siteSurfacesConsoleSurfacesMCP availabilitySurfacesMCP latency (p95)SurfacesMCP error ratePlatformAPI availabilityPlatformAPI latency (p95)PlatformAPI error rateIngestionReceiver latency (p95)IngestionIngest rejections (rate)DatabaseDatabase connectivityNotificationsAlert delivery failures (1h)NotificationsAlert delivery (p95)NotificationsEmail deliverySurfacesStatus pageSurfacesDocs siteSurfacesConsoleSurfacesMCP availabilitySurfacesMCP latency (p95)SurfacesMCP error rate

The problem

Most status pages are fed the wrong signal.

Typed by a person.

The person

28 min

From the first 5xx to the first human update. The page said operational the whole time.

Checked by a ping.

The ping

200 OKGET /health4.7%checkout 5xx

Same minute, same service. The ping checks that the door opens.

Averaged for everyone.

The average

99.93%

Inside Initech's 99.5% contract. A breach of Acme's 99.99%. One shared page shows green to both.

Read from telemetry.

Observer

4 min

From the first 5xx to a public verdict, judged per customer.

Watch the replay

Proof

Your status page said “operational” for 28 minutes.

Checkout starts failing at 10:14. Watch it replay.

BUptime monitor

GET /health every 30s

Page says

All systems operational

  • 10:10:00GET /health200 OK36ms
  • 10:09:30GET /health200 OK33ms
  • 10:09:00GET /health200 OK47ms
  • 10:08:30GET /health200 OK44ms
  • 10:08:00GET /health200 OK41ms
Meanwhile, checkout 5xx0.08%

First public signal

Page matches reality

All quiet. Every page is green.

First public signal after 10:14

Manual status page

0min late

Typed at 10:42, 12 minutes after the first ticket.

Uptime monitor

Neverflipped

/health answered 200 OK while 5% of checkouts failed.

Observer

0min

Flipped at 10:18, 12 minutes before the first ticket.

Customer tickets start at 10:30. Only one page told customers first.

See Observer's own live page

On the record

Proof your customers can check.

After an incident: a record, not a recollection. A signed statement, the measured evidence and an update written from it.

Signed SLA statement

Change one figure and it stops verifying.

Observer signs each period's statement. Anyone can check it against our published keys, no account needed.

Verified.

SLA statement, September 2026

Acme Cloud for Globex

  • API availability99.9%99.751%
  • Database latency99.95%100.000%
  • Edge delivery99.5%99.994%
sha256 of the contentsb5ae902ab62ed46153367ffe55a64014a7effbba61197dcee2451d3a61fea4d2Signed by Observer, key obs-sign-1 · checkable without an account

Incident evidence

What was measured, attached to the incident.

The impact window, the checks and customers affected, SLO burn, nearby changes by timing only, and the data coverage.

Card payments failing at checkoutcomputed, not AI
Payment successUnhealthy, 2 changes
Checkout pageDegraded, 2 changes
Deploy a41f9c2by timing only
~3m before
CustomersGlobex, Northwind
2 marked affected · 3 with access
13:5014:1014:30
Checkout SLO budget61.0%

99.6% of expected samples carried a status · observed by acme-prod-eu

AI update

Drafted from the evidence. Published by a person.

Drafts are checked against the measurements first; one that guesses a cause or invents a number is refused.

Evidencecomputed, not AI
Started
2026-10-06 14:02 UTC
Impact
ongoing, unhealthy
Services
Checkout, Payments
Cause
none stated in any update
Update draftsAI draft · claim check

Some card payments at checkout have been failing since 14:02 UTC due to a database failover. Our team is investigating.

  • Refused: it states a cause no evidence or update gave. You see nothing rather than a wrong draft.

Some card payments at checkout have been failing since 14:02 UTC. Customers may see their payment declined or the checkout page load slowly. Our team is investigating and will post an update as we learn more.

  • No cause stated
  • Every number is in the evidence
  • Impact still ongoing, as measured
PublishNothing is public until someone publishes.

Sources

Every signal your engineers trust.

One evaluator sits behind all of them. The value on your dashboard is the value on your page.

SourceReads

Prometheus

Prometheus: Healthy, 0.212 < 0.25

key: checkout-p99source_type: prometheussource_config:  query: |    histogram_quantile(0.99, sum by (le) (      rate(http_request_duration_seconds_bucket{        job="checkout"}[5m])))thresholds:  healthy_operation: under  healthy_value: 0.25  unhealthy_operation: over  unhealthy_value: 0.5

Latest sample

0.212s

Verdict

Healthy0.212 < 0.25

Evaluated on the agent host with strict operators; the cloud gets only the value and the verdict.

Sources

0

Categories

0

Connection strings or certificates stored in the cloud

18

DSNs, certificates and private keys are env var names in your YAML, resolved on the agent host.

Financial services

Selling to payment firms or other regulated customers?

Under DORA, their reporting clock can start with your outage. Observer gives them timestamped facts and records they can verify.

Their clock
If your outage is their major incident, their first report is due within 4 hours of classifying it.
Measured facts
Start, end, affected services and customers: timestamped, from your metrics.
Signed records
Monthly SLA statements and incident evidence exports, hashed and signed. On Business.

How it works

Ten minutes from install to a public page.

The agent evaluates every metric inside your network. Only the reading, its verdict and a heartbeat cross.

012 min

Run the agent.

A container or a binary on any host near your data. It only dials out; nothing connects in.

Your network No inbound ports

Prometheus
Postgres
Loki
Agentobserver-agent
terminal
# Any container runtime: Docker, Kubernetes, ECS
$ docker run -d --name observer-agent \
-e AGENT_KEY=obs_live_… \
ghcr.io/useobserver/agent:latest
# Or the binary for Linux, macOS or Windows
$ AGENT_KEY=obs_live_… ./observer-agent-linux-x64
025 min

Define what working means.

A query and two thresholds per metric, compared with strict operators.

under 250 between over 500
250500

Reading 312 is degraded. 500 is not over 500.

observer.yaml
key: checkout-p99
source_type: prometheus
source_config:
query: histogram_quantile(0.99, sum by (le)(rate(http_req_bucket[5m])))
thresholds:
healthy_operation: under
healthy_value: 250
unhealthy_operation: over
unhealthy_value: 500
03seconds

The page follows the signal.

Verdicts flip the page within seconds and reach your channels. Recovery flips it back.

Agent
Cloud
Page

{ metric_id, value, status, timestamp }

Outbound only, HTTPS 443. No raw series, no log lines, no credentials.

Source

Open source agent.

Apache-2.0. Read exactly what runs inside your network and build it yourself.

github.com/useobserver/agent

Network

Outbound only.

The agent dials out on HTTPS 443. Nothing listens for Observer, so there is no inbound port to open.

Secrets

Secrets stay on your host.

connection_string_ref, token_ref and client_cert_ref name an env var. The agent host resolves the value; the cloud only stores the name.

Resilience

Replicated, with no gaps.

A continuously replicated standby takes over if the primary fails. The agent buffers verdicts through an outage and drains them on reconnect.

Platform

Everything after the verdict.

One verdict per metric drives every page, drafts the incident, burns the right budget and reaches every channel.

Customer-scoped pages

One probe. A verdict per customer.

Each customer's page is judged against their own SLO target, so a strict contract flips before a loose one.

A checkout availability reading of 99.93% is operational for Globex (target 99.9%) and Initech (target 99.5%), and degraded for Acme (target 99.99%).

Incidents

Drafted automatically. Published by a human.

A confirmed breach drafts the incident, AI writes the update from the evidence, and on-call publishes it in one click.

  1. Threshold crossed14:02
  2. Dwell held, 2 min14:04
  3. Draft ready14:04

Untouched drafts expire after 24h.

Notifications

Every channel your team already watches.

One status change, rendered natively for 10 alert channels, plus RSS and Atom feeds.

metric.status_changedcheckout-apihealthy→degraded
  • Slack (Slack)
  • Teams (Microsoft Teams)
  • Discord (Discord)
  • Telegram (Telegram)
  • PagerDuty (PagerDuty)
  • Splunk (Splunk On-Call)
  • Grafana (Grafana IRM)
  • Jira (Jira)
  • Email (Email)
  • Webhook (Signed webhook)
  • RSS (RSS and Atom)
  • Recoveries always deliver

Also on the platform

Compare plans

SLOs and error budgets

Budgets that match the contract.

  • Rolling windows1 to 365 days
  • Burn alerts
  • Maintenancekept out of the math
SLO monitoring

Internal pages

Status pages for platform teams.

  • Password
  • IP allowlist
  • JWTfrom your app
  • Sign-inGoogle, Microsoft
Internal teams

Also included

The details customers notice.

  • Custom domainsautomatic TLS
  • Branding and themesper page
  • Ten languagesArabic and Chinese included
  • Embeds and badgesbadge.svg
  • Maintenance windowsscheduled
  • Heartbeatscron jobs and backups
Heartbeats

Reporting

Numbers that survive an audit.

  • Reliability CenterEvery plan
  • Executive dashboardPro
  • SLA reportsPro
  • SLA LedgerBusiness
  • Compliance evidenceBusiness
Reliability Center

Developers

Status as code.

Config lives in your repo and ships from CI. Everything else goes through the REST API or MCP.

YAML configobserver.yaml in your repo, applied from CI.
CLIPlan, apply, and export what you already have.
REST APIEverything under /api/v1, described by OpenAPI.
MCP serverOne tool per API operation, under your key's scopes.

Live page

Our status page runs on Observer.

Nobody on our team updates it by hand.

All systems operational
Open the live page

Pricing

Flat pricing. No per-seat.

Plans differ by quotas, not headcount. Move up or down any time.

Free

Single status page, single agent.

$0 per month

Start free

Includes

  • 1 status page
  • 1 agent
  • 10 metric definitions
  • 5 subscribers
  • 7d metric history

and 1 more

Starter

For a single product launching to its first paying customers.

$19 per month, billed monthly

Start Starter

Everything in Free, plus

  • 3 agents
  • 50 metric definitions
  • 3 SLOs
  • 1 custom domain
  • 5,000 subscribers

and 5 more

Pro

Most popular

For SaaS that already has customers.

$79 per month, billed monthly

Start Pro

Everything in Starter, plus

  • 3 status pages
  • 10 agents
  • 500 metric definitions
  • Unlimited SLOs
  • 5 custom domains

and 7 more

Business

For B2B SaaS scaling past 25 customers.

$199 per month, billed monthly

Start Business

Everything in Pro, plus

  • 10 status pages
  • 25 agents
  • 1,000 metric definitions
  • 10 custom domains
  • 100 customer-scoped pages

and 5 more

Enterprise

Contract

Multi-product orgs, unlimited everything, priority support.

Everything in Business, plus

  • Unlimited status pages, agents, metric definitions, custom domains and customer-scoped pages
  • 500,000 subscribers
  • Custom metric history
  • Your own identity provider (OIDC)

Every plan: All sources, incidents and maintenance windows, and the audit log.

Compare every feature

FAQ

Straight answers.

Still have questions?

Connect one metric. See its record in ten minutes.