Skip to content

Incidents & maintenance

Incidents and maintenance can be created by admins and service managers for all services, and by service owners for their own — their service selection shows only their own services. Updates, reviews and maintenance edits are maintained by admins, service managers and SLA managers for all services, and by service owners for incidents and maintenance whose components all belong to them. Closing is allowed for admins, service managers and service owners (own services); internal notes are written by admins and service managers only. Service owners can maintain the exact outage times of closed incidents of their services. See Roles & login.

Creating an incident

Open Operations → Incidents → New incident.

  1. Title: short and understandable for customers, for example "Checkout errors in EU region". At least 3 characters.
  2. Incident status: Investigating (default), Identified, Monitoring or Resolved.
  3. Occurred at (in time zone): when the problem actually started. This can be earlier than now. The field is recorded in the time zone of the settings.
  4. Responded at (in time zone): when the team responded. The basis of the response time in the SLA metrics.
  5. Impact: No impact, Minor (default), Major or Critical.
  6. Set affected components to: one shared status for all selected components: Operational, Degraded Performance, Partial Outage (default) or Major Outage.
  7. Open outages (optional): if an outage is already running, select it. The incident then takes over that window without creating a second one. The outage's components are added automatically.
  8. Affected components: select one or more services. At least one component or open outage is required ("Select at least one affected component or open outage").
  9. First update message: the first public update, 3 to 2000 characters.

Click Create incident. Saving sends an incident_created notification to the channels that are enabled for the affected services.

Working on an incident

The Incidents list shows the sections Active and Resolved and reviewed. Closed incidents only appear in the Closed section after clicking Show all incidents; Hide closed hides them again. Open incidents open with Manage, closed ones with View.

Depending on the status, the detail page has these cards:

Card When What it does
Post update always; read-only when reviewed or closed Fields Occurred at, Responded at, Resolved at (only for status Resolved), Incident status, Component status (default "Keep current status"), Affected services (the selection replaces the previous one) and Message. As a service owner you only see your own services there. Update incident posts the timeline entry. For a resolved incident, any status other than Resolved reopens it.
Internal Notes always Private notes for the team, never shown publicly. Everyone can read them; only admins and service managers can write. Add Note, at most 2000 characters.
Outage times (exact) when resolved, reviewed or closed For each affected component Status during outage, Outage start and Outage end. Save outage times replaces the original windows in the history. Allowed for admins, service managers and owners of all affected components.
Review incident when resolved Review notes (root cause, measures), 3 to 5000 characters, plus correctable times Occurred, Responded and Resolved at. Save review → reviewed sets the status to reviewed and sends incident_reviewed.
Close incident when reviewed Close incident freezes the incident and sends incident_closed.

Rules to know:

  • Moving back from resolved to an open status reopens the incident. The resolved time is reset.
  • A reviewed or closed incident accepts no more timeline updates ("A reviewed or closed incident cannot receive timeline updates."). The exact outage times can still be changed.
  • Each update triggers a notification according to the templates, for example incident_updated or incident_resolved.

Maintenance windows

Open Operations → Maintenance → New maintenance.

  1. Enter a Title and optionally a Description (optional).
  2. Set Start and End, both in the time zone of the settings. The end must be after the start ("End must be after start").
  3. Select the affected services under Affected components.
  4. Click Schedule maintenance. Creating it sends maintenance_scheduled.

The Maintenance list shows Title, Window, Components and Status. Until a maintenance window is completed, it offers Edit (save changes with Save changes) and Mark complete. A completed maintenance window can no longer be edited ("Cannot edit a completed maintenance.").

The window moves through three phases:

Phase Meaning
Scheduled Planned, not yet started. Shown as upcoming on the public page.
In progress Starts automatically at the start time. Affected components show "under maintenance". A maintenance_started notification is sent once.
Completed Use Mark complete when the work is done. This sends maintenance_completed. If it is not completed manually by the end time, the worker sets it to Completed automatically at the scheduled end. This automatic completion sends no notification.

Maintenance is not an outage. It does not raise the outage counter on the public page; it appears under active maintenance and in the maintenance section instead. Whether outages during maintenance count toward SLA availability is set by the SLA schedule's option Ignore Outages during maintenances, see SLA management.

Info

If the worker is not running when a maintenance window starts, the start notification is sent as soon as it runs again, as long as the window has not ended. The automatic completion at the end time is always caught up. Make sure the worker is running, see Operations, backup & restore.

Tips for communication

  • Post an update at least every thirty minutes during a major incident, even if only to say that work continues.
  • Use "monitoring" once a fix is in place, and "resolved" only when the service is confirmed to be working.
  • Keep internal notes factual. They can later support the review.
  • Fill in the review while the details are fresh. The review notes appear publicly in the timeline, and an SLA report can only be generated once its incidents are reviewed.