Skip to main content

Statuspage

Rationale

Statuspage is our main communication tool with users regarding our product's health and incidents. This helps us inform quickly, clearly, and transparently about outages, performance degradations, or any other eventuality in our components or external dependencies.

The main reasons why we chose it over other alternatives are:

  1. It provides a simple hub where incidents can be written quickly, providing all the necessary information.
  2. It is fully customizable for every need.
  3. It provides the possibility to display real-time dependencies status.
  4. It brings easy multiple integration options with other Atlassian products we use and also with external tools.
  5. Its API provides quite a few options to run automations and get data easily.

Alternatives

The following alternatives were considered but not chosen for the following reasons:

  1. BetterStack: It was our main status page for some time, but it finally did not meet our strict security requirements.

Note: Instatus, Cachet and Uptime are other alternatives. A review is pending.

Usage

We use Statuspage for:

  1. Inform internal and external users about our products' status on status.fluidattacks.com.
  2. Create, manage, and display incidents.
  3. Give updates on incident status.
  4. Create and display incidents' postmortem.
  5. Display components' uptime timeline.
  6. Display third-party dependencies' status.
  7. Send notifications via email, SMS, webhook, Slack, and RSS to our status page subscribers.
  8. Provide a historical register of our incidents and their respective details.

We do not use Statuspage for:

  1. Schedule maintenance events.
tip

Refer to the Status Page section to get deeper into the usage of every section of the Fluid Attacks' status page.

Guidelines

  1. To post an incident or manage Statuspage settings, you must be added as a team member and log in to the Statuspage hub.
  2. Statuspage team members can quickly post incidents by clicking on the Create incident button in the main screen's center.
  3. Once the incident is created, the user can manage the incident through multiple options such as updates, states, components and more.
  4. When the incident is closed, the user can click the button Write postmortem next to the respective incident in the registry to provide further details about the incident to the subscribers.
tip

To expand the information about incident management, please refer to the Incidents section.