An incident reports an unplanned event; a maintenance announces planned work. Both are shown on every page that contains an affected component, and both are sent to the subscribers who follow such a component. ## Incidents An incident has a title, an impact, affected components with the state each gets while the incident is open, and a timeline of updates. The impact is `none`, `minor`, `major` or `critical`. Every update carries a phase: - Investigating: the cause is not known yet. - Identified: the cause is known and a fix is being worked on. - Monitoring: a fix is in place and its effect is watched. - Resolved: the incident is over; its components return to operational. An update can be corrected afterwards. The correction is shown as a correction, and earlier versions stay available. An incident can be entered after the fact with an earlier start, so the history is complete. A resolved incident can get a post-incident report in Markdown, which is published with the incident when the operator chooses to. Every incident has a permanent address of the form `/en/incidents/<year>-<number>/<title>`, such as `/en/incidents/2026-0187/exact-online-netherlands-invoices-time-out`. ## Templates A template fills the title, message, phase and impact of a new incident. Placeholders such as `{{component}}` and `{{locations}}` are replaced when the template is used. Templates are maintained under [[Invantive Cloud Status/Menu/Incident Templates|Incident Templates]]. ## Maintenance A maintenance has a window with a start and an end, affected components and a message. Its phases are: - Scheduled: announced, the window has not started. - In progress: the work is being carried out; the components are under maintenance. - Verifying: the work is done and being checked. - Completed: the components return to their state. The maintenance starts and completes by itself at the boundaries of the window, unless the operator switches that off. Probes of the affected components can be muted during the window, so planned downtime opens no incident and does not count against the uptime. A maintenance can recur, such as every first Sunday of the month. The recurrence is written as the part of an `RRULE` of [RFC 5545](https://www.rfc-editor.org/rfc/rfc5545) that a maintenance needs: `FREQ` daily, weekly or monthly, `INTERVAL`, `BYDAY` with an optional ordinal such as `1SU`, and `COUNT` or `UNTIL`. For example `FREQ=MONTHLY;BYDAY=1SU`. Subscribers receive reminders a chosen number of minutes before the window, such as 4320 and 60 for three days and one hour.