Status pages for reducing support tickets

During an outage everyone asks the same question. A status page answers it once, for everyone, at the same time.

What it looks like without one

In the first hour of an outage:

  • Every customer writes separately: "is it down for everyone or just me?"
  • Support answers one at a time while engineering is putting out the fire
  • When it is over, nobody remembers who was told and who was not

What does not help

A post on social media

It reaches the people who follow you and disappears within the hour. Someone arriving two days later finds nothing.

An email to everyone

It goes out late because it needs approval, and it often reaches the accounts that were not affected.

Silence

The cheapest option today and the most expensive tomorrow: the customer decides for themselves what is going on.

What the page changes

One answer for everyone

The link goes in your support auto-reply, your in-app notice and your email signature.

Components customers recognise

Not server names but services: sign-in, payments, API. It is clear what is affected and what is not.

Subscriptions

Customers subscribe and follow it themselves, from "investigating" to "resolved".

Maintenance announced ahead

A scheduled window turns "why is it down?" into "I knew about that" — and that costs zero tickets.

Live in a day

  1. 1Create the page on your own domain
  2. 2Name the components in the customer's language
  3. 3Attach monitors so the status changes itself
  4. 4Put the link in your support auto-reply and your app
  5. 5During the next incident, publish updates there instead of one email at a time

The first incident with a page is usually where the difference shows up in the numbers.

Frequently asked questions

Does a status page really reduce tickets?

It reduces the tickets that ask the same question. The link in the auto-reply and in the app does most of the work.

Can I report on only part of the service?

Yes. A report is attached to specific components, and subscribers can receive only the events that touch them.

Will the page work when our system does not?

Yes — it runs on our infrastructure, not yours. That is the point.

Answer once, not a hundred times

Create a pageAll use cases