Monitorion automatically opens, tracks, and closes incidents when your monitors detect failures. Every incident has a full timeline, a duration, and links back to the raw check data.
Monitorion does not alert on the first sign of trouble. Instead, it waits for N consecutive failures before opening an incident and sending alerts. This prevents false positives from brief network hiccups.
Open a monitor, go to Edit, expand Advanced Settings, and look for Alert after N failures. The default is 3 consecutive failures. You can set this between 1 and 10.
For monitors with long check intervals (hourly or daily), waiting for 2 or 3 consecutive failures could mean 2-3 hours pass before you are notified. Monitorion applies a smart override: if a monitor's interval is 60 minutes or longer, an incident is created on the very first failure, regardless of the configured threshold. For all faster monitors the configured N is respected.
The Check Now button on a monitor runs an on-demand check that acts as a live test of the whole alert pipeline:
Automatic scheduled checks still use the N-failure threshold above (with the smart override for slow monitors). Check Now is the exception that acts at once.
An incident enters the Open state when the failure threshold is reached. Alerts fire immediately. The incident appears in your dashboard and on any linked status page for subscribers.
A team member can manually acknowledge an open incident to signal that someone is investigating. The incident moves to Acknowledged, which suppresses repeat alert notifications while investigation is in progress. The incident will be automatically resolved when the monitor reports successful checks again.
As soon as a check succeeds — the next scheduled check, or a manual Check Now — the incident is automatically marked Resolved. A recovery alert is sent through all configured channels, and status-page subscribers receive an email notification. The incident is then archived in your incident history.
You can also manually resolve an open incident from the incident detail page. This is useful when a fix has been deployed outside the normal check cycle and you want to close the incident immediately.
Every incident is automatically classified with a severity level when it is created. This helps you prioritize response efforts when multiple incidents occur simultaneously.
| Severity | When assigned |
|---|---|
| Critical | SSL or domain expiring within 7 days, heartbeat monitor down |
| Major | Service down, request timeout, blacklisted |
| Minor | Warnings, degraded performance, all other failure types |
Severity is assigned automatically based on the monitor type and failure reason. It cannot be changed manually. The severity badge appears on the incidents list and incident detail page.
After an incident is resolved, you can write a postmortem to document what happened, why it happened, and what you will do to prevent it from happening again. Postmortems are written directly on the incident detail page.
Open a resolved incident from the Incidents page and scroll to the bottom. Click Write Postmortem, fill in the fields, and save. The postmortem is attached to the incident and can be viewed by any team member with access.
Schedule planned downtime to prevent false incidents and alert fatigue during deployments, database migrations, or infrastructure changes.
Go to Maintenance in your dashboard and click New Window. Configure:
Every incident has a detail page with a full chronological timeline of events.
Start time
The exact timestamp of the first failed check that contributed to the incident threshold.
Error message
The raw error returned by the check — HTTP status code, timeout message, connection refused, certificate error, and so on.
Status changes
Each transition (Open → Acknowledged → Resolved) is logged with its timestamp. If the service flaps between up and down multiple times, each change is recorded.
Recovery time
The timestamp of the first successful check after the service came back online, before the monitoring grace period completed.
Duration
Total time from the first failed check to the incident being resolved. Displayed prominently at the top of the incident detail page.
The Incidents overview page shows your MTTR — the average duration across all resolved incidents in the selected time range. MTTR is calculated as:
Track this metric over time to measure the effectiveness of your on-call processes and infrastructure improvements.
Resolved incidents are kept in your account history for a period that depends on your plan. Older incidents are permanently deleted after the retention window expires.
| Plan | Retention | Notes |
|---|---|---|
| Free | 7 days | Last 7 days of incident history visible |
| Pro | 30 days | Sufficient for monthly SLA reporting |
| Business | 90 days | Quarterly trend analysis and reporting |
| Agency | 365 days | Full-year history for SLA audits and client reports |
Tip: Before incidents expire you can export them to CSV from the Incidents page. This is useful for long-term SLA reporting on plans with shorter retention windows. CSV export is available on Pro and above.
Start monitoring for free and let Monitorion handle incident tracking automatically.