A status page lets the people who use your app check whether it’s working, without asking you. It shows each part of your service, its uptime over the last 90 days, and any incidents you’ve written. Nothing private is on it.

Turn it on

Open Status page in the sidebar.

Components

Each component has a name, a short description, and a source that says how its state is known: A new page starts with four components: API, Sign-in, Realtime and Background jobs. Rename them in your users’ words, remove what they don’t care about, and add manual components for things outside Pawabase that your service depends on. Probed components are checked every five minutes. A component is: Each day’s checks roll up into a daily uptime bar, so visitors see 90 days of history per component.

Incidents

When something is wrong, open an incident, even before you know the cause. While an incident is open, the components it names show at least as bad as its impact says, whatever the probes say. Post updates as you learn more; each update has a status and a message, and can change the impact. Set the status to resolved to close it. A good update says what people experience, what you’re doing, and when you’ll update next:
Identified · Sign-ins are failing for some people using Google. We’ve found the cause, a change at our provider, and are rolling out a fix. Next update in 30 minutes.
Delete an incident only if it was opened by mistake; otherwise resolve it, so the history stays honest.

The public address

The page is served by your project’s API, with no key needed: If the page isn’t published, these answer 404. Use the JSON to show a banner in your own app when something is degraded:

From code

Good practice

  • Open early, update often, resolve honestly. A quiet status page during an outage costs more trust than the outage.
  • Name components in your users’ words: Checkout, not gateway.
  • Link to it from your app’s footer, help centre and error screens.
  • Pair it with alarms, so you find out before your users.