The live board is not part of the Markdown view of this page. Read the current state as JSON at
/docs/status?format=json.
What is monitored
Component
How it is checked, every minute
API
An unauthenticated call to the v1 API. A healthy API refuses it with a 401 and a JSON body.
Sign-in
The dashboard sign-in page loads, and the database answers.
Webhook delivery
How long the oldest event has waited in the delivery queue. Slow after 10 minutes, failing after 60 minutes.
Widget
An unauthenticated call to the widget service. A healthy service refuses it with a 400 and a JSON error.
Hosted sites runtime
The status call hosted sites make at load time answers with JSON.
Email delivery
How long the oldest transactional email has waited to be sent. Slow after 15 minutes, failing after 60 minutes. Bulk sends are not counted.
How a state is decided
Outage after three checks in a row fail, so one dropped check does not flap the page.
Degraded after three checks in a row that are slow (over 3 seconds) or failing.
Back to operational after two good checks in a row.
Maintenance while a person has posted planned maintenance for the component.
No recent data when the checks themselves have stopped reporting for more than 10 minutes. We do not show a green light we cannot back up.
A person can also post an incident that raises a component above what the checks show.
Each bar is one day (UTC). Uptime is the share of that day's checks that did not fail. A day is
amber below 99.9% and red below 99%. A grey striped bar is a past day on which fewer than half the expected
checks ran, because the checker itself was not running; we do not call such a day healthy. Checks that fail
during announced maintenance still count against uptime.
What this page cannot see
The checks run from our own infrastructure. If that infrastructure is completely unreachable, the checks stop too, and the page shows No recent data or may be unreachable itself. It is not an outside observer.
The checks record into our own database. A database outage is therefore more likely to show as missing data than as a red bar.
Checks reach the public address of each service. They do not test a particular customer's key, Space, site or webhook endpoint, and they do not see problems on the other side of the internet from us, such as a receiver that is down.
A problem that affects only some requests, one region or one feature can pass every check.
Third-party services we depend on, such as payment and email providers, are not checked directly. Email delivery measures our queue, not whether a recipient's inbox accepted the message.
Feeds
Follow incidents with the Atom feed, or read the same data as
JSON. Both are public, need no key, and are cached for a minute.
Something broken that is not on this page? Open a request with Support.