---
title: "Incidents and status pages"
description: "Declare an incident, keep everyone updated from one place, and publish a status page people can read without signing in."
url: "https://support.outpostplatform.com/guides/incidents-and-status-pages/"
product: "depot"
type: "how-to"
status: "stub"
ai_summary: "Guide to incident management and public status pages in Outpost. Covers declaring an incident, severity and components, posting updates that reach affected clients, publishing a status page anybody can read, and writing the review after the incident is closed."
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/guides/incidents-and-status-pages.md"
license: "CC BY 4.0"
---

# Incidents and status pages

When something is broken for more than one person, the work splits in two:
fixing it, and telling everybody. Outpost incidents exist for the second half,
so that one person posting one update reaches the console, the affected clients
and a public status page at once. This guide is for whoever runs an incident.

<!-- TODO: write this page against the how-to template.

Sections:

- Before you begin: the incident permissions, and deciding in advance who
  declares.
- Declaring an incident: severity, affected components, affected clients.
- Posting updates, and how often is often enough.
- What each audience sees: the console, the affected client, the public page.
- The status page: what it publishes, where it is hosted, and what it never
  discloses.
- Linking an incident to the alerts and tickets that led to it.
- Resolving, and the difference between resolved and monitoring.
- Writing the review afterwards, and where it lives.
- If something goes wrong: an incident that alarms clients who are not
  affected, and a status page that disagrees with the console.
-->

Follow the [how-to template](https://gitlab.com/outpostplatform/docs/-/blob/main/templates/how-to.md).