Report an incident
Report an incident manually in Servor — set its title, status and impact, write a message and publish it to your status page and components.
When something breaks, an incident is how you tell your users what's happening, what's affected and when it's fixed. This page walks you through reporting an incident by hand — the fastest way to communicate a problem you already know about, before or instead of waiting for a monitor to catch it.
If you'd rather Servor open incidents for you when a monitor goes down, see Automatic incidents.
Before you start
- You need member access or higher. Viewers can read incidents but can't create them — see Roles and permissions.
- To publish an incident publicly, you need a status page. Linking is optional: you can log an incident privately and attach a page later.
Report an incident
Open Incidents and start a new one
Go to Incidents and click Report an incident. A form opens where you describe the problem and its current state. Report an incident in Servor
Give it a clear title
Write a short, plain-language title your users will understand at a glance — for example "Elevated API error rates" or "Dashboard login failures". Avoid internal jargon and server names.
Set the status and impact
Pick the current status and the impact level. Together they tell readers how bad it is and how far along you are. See Status and impact below for what each value means.
Write the first message
Add a short message describing what you know right now: what's affected, what users might see, and that you're investigating. It's fine to keep it brief — you'll post updates as you learn more.
Link a status page and components (optional)
Choose a status page to publish to, then select the components affected (for example API, Dashboard, Database). The linked components switch to the incident's impact automatically, so your status page reflects reality without extra edits. See Add components.
Publish
Publish the incident. If you linked a status page, it appears immediately on the public timeline and your subscribers are notified.
Communicate early, even with little information
A short "We're investigating reports of…" published in the first few minutes builds far more trust than a perfect message thirty minutes later. You can refine the details in your next update.
Status and impact
Two fields describe an incident, and they answer different questions.
Status — where you are in handling it:
| Status | Meaning |
|---|---|
| Investigating | You've confirmed something is wrong and are looking into it. |
| Identified | You know the cause and are working on a fix. |
| Monitoring | A fix is in place; you're watching to confirm it holds. |
| Resolved | The incident is over — see Update and resolve. |
Impact — how badly users are affected:
| Impact | Meaning |
|---|---|
| Minor | Limited or degraded — most users are fine. |
| Major | A significant feature or service is broken for many users. |
| Critical | A full outage — the service is unusable. |
Impact drives how the incident looks on your status page and how prominently it's shown. Set it honestly — under-reporting a critical outage as "minor" erodes trust faster than the outage itself.
Linking components
Components are the parts of your service shown on a status page. When you link an incident to one or more components, they inherit the incident's impact and turn red/orange automatically, then return to operational when you resolve it. This keeps the top of your status page accurate without a second manual step.
If you haven't set components up yet, add them first — Add components — then come back and link them.
Automating it
You can also open and update incidents over the API, which is handy for wiring
your own alerting into Servor. It needs the incidents:write
scope. See the Incidents API.