Openedauto
On the first failed check
A monitor check comes back failing. SolidOps opens an incident the moment it sees the state change, with no button to press and nothing to file.
Feature · Incidents
Incidents that open and close themselves.
When a check fails, SolidOps opens an incident, tracks every state change on a timestamped timeline, and closes it when the check recovers. Live today.
Incident · inc_4c1a
--:--:--demo data
Linked checkCHK-HTTP · billing.acme.io
- 14:02:08OPENEDbilling.acme.io · 503 · check failed
- 14:03:41ONGOINGstill failing · 200 · 642ms · degraded
- 14:05:12RESOLVEDcheck recovered · 200 · 121ms
Auto-resolvedOpen for 3m 04s
one incident, start to finish · figures are demo data
3 states · live
An incident manages its own life.
Every incident moves through three states. A failing check opens it, a recovering check resolves it, and SolidOps drives the whole path, so nothing waits on a human to remember.
Ongoinglive
While the check keeps failing
The incident stays open and every further state change is appended to its timeline. The clock keeps running, so the open duration is always current.
Resolvedauto
On the first recovered check
The check passes again. SolidOps closes the incident on its own, stamps the resolve time, and the total open duration is fixed in the record.
No manual open, no manual close. The check drives the state.
On the record
What every incident
keeps for you.
An incident is a record, not a notification that scrolls away. Four things are written and kept: the check that triggered it, every state change, how long it stayed open, and whether it is visible to your users.
Linked check
CHK-HTTP · billing.acme.ioEvery incident points back at the exact check that opened it, so the trigger is one click away.
State changes
3 entries · timestampedEach transition is appended to a timeline with its own timestamp: opened, every change while ongoing, resolved.
Open duration
3m 04sMeasured from the opening check to the recovering one. Fixed in the record the moment it resolves.
Visibility
public / privateMark an incident public or private. Private stays internal; public is the one you would show your users.
inc_4c1a · record
demo dataLinked checkCHK-HTTP · billing.acme.io
Opened
14:02:08
Resolved
14:05:12
Open for
3m 04s
State changes · 3
- 14:02:08OPENED503 · check failed
- 14:03:41ONGOING200 · 642ms · degraded
- 14:05:12RESOLVED200 · 121ms · recovered
Visibility
one stored incident · figures are demo data
2 on the roadmap · not built
What is honestly still coming.
Two things people expect next to incidents are not shipping today. They are listed here so the line between live and planned stays clear.
STATUSComing
Public status pages
Publish the timeline of a public incident to a hosted status page, so your users can read what happened without opening a ticket. The public flag is here today; the page it feeds is not built yet.
Builds on the public/private flag that ships now
MAINTComing
Maintenance windows
Schedule a window of planned work and suppress alerts inside it, so deploys and migrations do not open incidents or page anyone. Not built yet.
Planned work will not trip an incident
Listed as coming, not counted as done
v0.1 · live now
Let the incidents track themselves. You watch the timeline.
Auto-open on failure, a timestamped timeline, auto-resolve on recovery, all linked to the check that triggered it. Buy the monitoring core today, and the rest of the platform lands as it ships.