All docs
Monitoring & alerting
Incidents
An incident is the record of an outage while you work it: who owns it, what you know, what you did. This page covers declaring one, acknowledging, assigning, posting updates, resolving and writing the post-mortem, plus the automatic timeline that shows what changed on a server before things broke.
Declare an incident
Open Incidents in the Monitor menu and click Declare. Give it a title (“Checkout API returning 500s”), a severity — critical, major (the default) or minor — optionally the affected server and a first message.
Declaring does four things at once:
- •Sends an “Incident declared” notification to your channels under the Incidents category, and a push to the mobile app.
- •Assigns it to whoever is on call right now — the default on-call schedule’s primary. With no schedule, the person who declared it keeps it.
- •Emails confirmed subscribers of your public status pages that an incident is being investigated.
- •Starts the escalation clock for a critical incident: if nobody acknowledges it, the escalation steps page people.
Working the incident
| Action | What it does |
|---|---|
| Acknowledge | Records that you have it. Stops escalation for this incident. |
| Assign | Hands it to a teammate, or leaves it unassigned. Every change is logged as an update. |
| Post an update | Adds a message to the thread. Optionally moves the status at the same time. |
| Resolve | Marks it resolved and records the time. |
| Post-mortem | A free-text write-up (what happened, root cause, impact, action items) saved on the incident. |
Statuses are open → investigating → identified → monitoring → resolved. Each status change with a message is sent to confirmed status-page subscribers, so a public-facing update is one action, not a separate tool. The Incidents page lists open incidents first and resolved ones underneath, up to 200.
If an on-call schedule exists, the page shows who is on call and a Page on-call now button. If none exists it offers to set one up.
The incident timeline on a server
Separate from the incident record, every server has an automatic timeline. Open the server, choose the Activity tab and then Timeline, and pick a range of 4, 12 or 24 hours.
Opservo derives discrete events from the server’s snapshots, log clusters and findings over that window — a service that stopped, a disk that crossed a threshold, a burst of errors, a new finding that appeared — orders them, correlates them into a causal chain, and names the likely root cause at the top. Nothing needs to be configured; it reads the same data the health score already uses.
Use the timeline while an incident is open to answer “what changed first?”, then paste the answer into the incident thread or the post-mortem.
Last updated 2026-10-01. Found a mistake? Email hello@getopservo.com.
Related