Latest updateInvestigating01:33 UTC ()
p95 latency on the public API is above 500 ms. Requests are completing, more slowly than usual.
- Identified01:59
A slow query on the usage endpoint is holding connections. The fix is rolling out now.
ProductCustomer pages
Each customer signs in to their own status page.
One page behind your app's sign-in. Each customer sees the same services, measured against the targets in their contract, with the incidents that concern them.
status.example.com/?token=…
Skip to status
Acme
Active incidents
2 active incidents.
Nov 1301:33 UTC
Nov 1301:49 UTC
Latest updateIdentified02:02 UTC ()
Your dedicated export worker is behind. Exports finish, up to 15 minutes late.
At a glance
Uptime, 30 days
99.57%Services operational
3of 4Active incidents
2Service levels
1 exhausted · 1 at risk.
API availability
API
-17.6%budget leftBudget exhaustedTarget 99.95% (yours)
30 days
30 days
API latency under 500 ms
API
18.6%budget leftAt riskTarget 99%
30 days
30 days
Dashboard availability
Dashboard
88.4%budget leftOn targetTarget 99.95%
30 days
30 days
Services
3 of 4 services operational
- Operational
- Degraded
- Outage
- No data
API
2 checksDegraded30-day uptime99.5%
Oct 15Today
Metrics
- Request latency p95Degraded30-day uptime100%Oct 15Today
- Error rateOperational30-day uptime99.5%Oct 15Today
Dashboard
2 checksOperational30-day uptime100%
Oct 15Today
Metrics
- AvailabilityOperational30-day uptime100%Oct 15Today
- Page load p75Operational30-day uptime100%Oct 15Today
Webhooks
2 checksOperational30-day uptime100%
Oct 15Today
Metrics
- Delivery successOperational30-day uptime100%Oct 15Today
- Queue depthOperational30-day uptime100%Oct 15Today
Database
2 checksOperational30-day uptime100%
Oct 15Today
Metrics
- Replication lagOperational30-day uptime100%Oct 15Today
- Connections in useOperational30-day uptime100%Oct 15Today
Incidents
Last 24 hours
1 recent update, all resolved
Nov 1220:11 UTC1h
MinorResolvedWebhooks
- Investigating20:11
Webhook deliveries are running up to ten minutes late.
- Monitoring20:41
Workers are back to full capacity. Watching the queue drain.
- Resolved21:11
The queue has drained and every delayed event was delivered.
The status page itself, drawing sample data for three visitors to one page. Switch who is signed in, and scroll inside it.
Targets
Their contract, their number.
Override a target for one customer. The same readings are measured against it, so a stricter contract shows its own error budget.
Signed in as Globex
The standard 99.90% target.
status.example.com/?token=…
Service levels
1 tight.
API latency under 500 ms
API
18.6%budget leftAt riskTarget 99%
30 days
30 days
API availability
API
41.2%budget leftOn targetTarget 99.9%
30 days
30 days
Signed in as Northwind
Their contract says 99.95%.
status.example.com/?token=…
Service levels
1 exhausted · 1 tight.
API availability
API
-17.6%budget leftBudget exhaustedTarget 99.95% (yours)
30 days
30 days
API latency under 500 ms
API
18.6%budget leftAt riskTarget 99%
30 days
30 days
Override
Set per customer, per SLO.
Both pages read the same 30 days: 99.94% available. Against 99.95% that is an exhausted budget, recomputed every five minutes. Every other customer keeps the default.
Contract
Their SLA, on their page.
Record the terms you signed: the target, a rolling 30 days or a calendar month or quarter, whether degraded time counts as down, and whether planned maintenance is excluded. Their page shows the attainment for the period.
Console / Customers / Northwind
A customer's SLA terms in the console: target, window, what counts as down and the maintenance exclusion, per SLO.
Incidents
Tell only the customers it hits.
Mark who an incident affects. Keep it on the public page and email them too, or show it to them alone. Try the control from the incident form.
On the incident
Affected customers
Who can see it
Only Northwind can see this. Emails go to their linked subscribers on pages they have access to.
When you publish
| Audience | Sees it | Emailed |
|---|---|---|
| Public page[email protected] | No | No |
| Northwind[email protected] | Yes | Yes |
| Globex[email protected] | No | No |
| Initech[email protected] | No | No |
On a public incident, the resolve email also reaches anyone emailed earlier, even if you narrowed the list since.
Subscribers
Their people hear about their incidents.
Each subscriber can belong to a customer: from the page they signed in to, from your email rules, or by hand. Linked subscribers get that customer's private updates.
Email rules
- Northwind
- @northwind.com@partner.dev
- Globex
- *.globex.io@partner.dev
- Initech
- [email protected]
A new subscriber
Linked to GlobexEmail rule
*.globex.io: globex.io and its subdomains. The most specific rule wins.
Signed link
Subscribed while signed in.
A subscriber who signs up from a customer's page is linked to that customer. Rules never override it, and nothing is sent until they confirm by email.
Email rules
An address, a domain, or a domain and its subdomains.
The most specific rule wins and a tie links nobody. Shared mailbox domains are refused: "gmail.com is a shared mail provider. Add exact addresses instead." Apply new rules to existing subscribers in one step.
By hand
Link or unlink from the subscriber list.
A manual decision stays put. Rules and signed links never change it.
Access
Signed in through your app.
Your customers never get an Observer account. Your app vouches for them with a signed token, and the page does the rest.
Customers
Add them with the ID your app already uses.
One at a time, or import up to 500 from a CSV with their email rules, page grants and target overrides.
Grant
Grant the page.
A customer sees a page only once it has been granted to them. Grants and targets live on the customer.
Token
Your app signs a short-lived token.
Pro and upRS256, its subject the customer's ID, sent in a header or on the link. Observer checks it against your public key or JWKS URL, and refuses tokens older than an hour.
Preview
See their page before they do.
Open any customer's view from the console with their grants and targets applied, without minting a token.
Everyone else
The page checks the token before anything renders, and says why it refused.
- No token at all
- “Authentication required. Use the link your provider issued.”
- HTTP 401
- A token past its expiry, or issued over an hour ago
- “Your access token has expired. Request a new one from the page owner.”
- HTTP 401
- A token that fails verification
- “We couldn't verify your access token. Contact the page owner.”
- HTTP 401
- A valid token without a subject
- “Authentication token is missing the required subject claim.”
- HTTP 401
- A subject that matches no customer
- “Authenticated, but no matching customer record was found.”
- HTTP 403
- A customer this page was not granted to
- “Your customer record is not granted access to this page. Contact the page owner.”
- HTTP 403
Reliability
Numbers they can check, not take on trust.
Give the page a Reliability Center and send each customer a private link to their part of it.
Access links
Their contract, month to date.
Pro and upA link per customer and page opens their contract lines, attainment for the month so far and the statements delivered to them. Links expire after 90 days and can be revoked any time.
Plans
From Pro, not an enterprise contract.
Customers per plan
Each with their own grants, targets, SLA terms and linked subscribers. Customer-scoped pages are capped at the same number.
Pro
0customers25 customer-scoped pagesBusiness
0customers100 customer-scoped pagesEnterprise
UnlimitedUnlimited customer-scoped pages