• Components (e.g. servers, integration partners, functions within IT)
• Incidents
• Subscribers

Why a Status Page Needs Incident Reporting

Incident reporting is the primary value of having a status page. It spares your IT and/or customer support teams from the full onslaught of inquiries about the status of your product(s), but more importantly it shows your end-users that you care about their experiences using your tool(set) and that they can trust you to be transparent about when there are issues with it.

Incident reporting can take several forms. The most common is probably anticipated incidents – like scheduled maintenance or deployments. These alerts can be scheduled ahead of time, for everyone’s mutual convenience.

Alerts for unanticipated downtime also occur, and these can come in a variety of forms. If you’ve got an integration set up with your application performance monitoring (APM) tool, they can be live or delayed (perhaps you don’t want an alert going out unless an issue has been an issue for several minutes). Regardless of whether you’ve got an APM integration set up or not, you can post retroactive incident alerts as well.

Incident reporting can also be set up by component or sub-component. Perhaps only those using a certain product out of your total suite of offerings or only those hosted on a certain server are impacted by a given performance issue – no need to send a communication to every end-user, only notify those impacted.

Finally, for any given incident report on your status page, you can select whether it counts towards downtime or not (for purposes of an SLA, for instance).

Status Page Subscribers

Subscribers extend the value of a status page by making it even more convenient for end-users to be notified when there are issues.

Rather than having to come back and check your hosted status page when they suspect there may be an issue, they can elect to automatically receive notifications via their preferred communication method (e.g. email, SMS/text, Slack, tweet, etc.).

As Eric notes in the video, end-users can subscribe (or be subscribed by you) by specific component or sub-component, so again they are only receiving alerts that are relevant to their individual ability to access and use your products.

Next week, I’ll share Eric’s video covering setting up integrations (such as APM integrations mentioned above), and as I did here provide some additional context to why they are an important part of your downtime communication plan.