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 so you can conduct a proper post-mortem.
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, and look for Alert after N failures in the alerting section. The default is 2 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.
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.
When the monitor sustains the required consecutive successes, 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.
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.
All past incidents, timelines, and MTTR are available in your dashboard.