> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Publish and manage events
> Learn how to publish incidents and maintenance events on your status page, manage event lifecycles, and add timeline updates
Status pages communicate service status changes through **events**. Flashduty Status Pages support two event types: **incidents** and **maintenance**, corresponding to unexpected outages and planned maintenance scenarios respectively.
## Event types and statuses
### Incidents
An incident represents an unexpected event that affects service availability. Incidents have the following lifecycle statuses:
| Status | Description |
| ----------------- | --------------------------------------------------------------- |
| **Investigating** | The team is aware of the issue and investigating the root cause |
| **Identified** | The root cause has been identified and a fix is being developed |
| **Monitoring** | A fix has been implemented and recovery is being monitored |
| **Resolved** | The issue is fully resolved and service is back to normal |
### Maintenance
Maintenance represents a planned service change event used to notify users in advance of potential service impact. Maintenance has the following lifecycle statuses:
| Status | Description |
| ------------- | ---------------------------------------------------- |
| **Scheduled** | Maintenance has been planned but has not started yet |
| **Ongoing** | Maintenance is currently in progress |
| **Completed** | Maintenance has finished |
Components are marked **Under Maintenance** only during the maintenance's actual execution window (from the status transition to **Ongoing** until it is closed). A scheduled maintenance that has not yet started does not mark any components and does not affect availability charts or the calendar view.
***
## Publish an event
In the status page detail view, incidents and maintenance have their own independent entries:
* **Publish an incident**: go to the **Incidents** page and click **New incident**; to backfill a historical incident, click **Retrospective incident**
* **Publish a maintenance**: go to the **Maintenance** page and click **Schedule maintenance**
Configure the following fields:
| Field | Description |
| ------------------------------------ | --------------------------------------------------------------------------------------------------- |
| **Incident name / Maintenance name** | Brief title for the event, displayed publicly on the status page (required) |
| **Current status** | Initial status of the event |
| **Message** | Detailed description of the event (required), shown on the status page to describe the event status |
| **Affected components** | Select components affected by this event and set an impact status for each (at least 1 required) |
| **Notify subscribers** | Whether to send notifications to subscribers when publishing |
When publishing a maintenance, you must also fill in the **Impact window** (planned start and end times), and the end time must be later than the start time.
The **Responders** field is only available via the API / CLI; the console publish form does not offer this option.
Every event requires at least one timeline update. The system automatically generates an initial update record based on the information you provide.
After confirming the details, click **Publish incident** or **Publish maintenance** to create the event.
### Component impact statuses
When publishing an event, you need to specify the current service status for each affected component:
| Status | Description |
| --------------------- | ------------------------------------------------ |
| 🟢 **Operational** | Service is operating normally |
| 🟡 **Degraded** | Service is available but performance is affected |
| 🟠**Partial Outage** | Some functionality is unavailable |
| 🔴 **Full Outage** | Service is completely unavailable |
| Status | Description |
| ------------------------ | ----------------------------- |
| 🟢 **Operational** | Service is operating normally |
| 🔵 **Under Maintenance** | Service is under maintenance |
When an event reaches a terminal status (Resolved for incidents, Completed for maintenance), all affected components must be set back to Operational.
### Markdown formats supported in messages
The editor for event messages and timeline updates supports the following Markdown elements, which public status pages render in the same format:
| Format | Syntax example |
| -------------- | --------------------------------------------------------------------------------- |
| **Bold** | `**Important notice**` |
| *Italic* | `*about 30 minutes*` |
| Link | `[View details](https://example.com)`, opened in a new window |
| Unordered list | `- Scope of impact` |
| Ordered list | `1. First step` |
| Table | Standard GFM table syntax; the editor toolbar provides an **Insert table** button |
Unsupported elements (such as headings and images) render as plain text on the public status page. For security, links only accept `http` / `https` URLs.
On the status page landing page, each event's latest-update description is clamped to a maximum height of about 280px, with a bottom fade hinting at more content. The full content is available on the event detail page.
***
## Timeline updates
After publishing an event, you can add **timeline updates** to record progress and keep subscribers informed.
Each timeline update can include:
| Content | Description |
| ---------------------------- | ----------------------------------------------------------- |
| **Timestamp** | The actual time this update corresponds to |
| **Status change** | Advance the event to its next lifecycle status (optional) |
| **Message** | Narrative text about the current progress (required) |
| **Component status changes** | Adjust the service status of affected components (optional) |
Timeline updates follow these invariants, applied uniformly to both incident and maintenance events:
* **Append**: a new update's timestamp must be **greater than or equal to** the timestamp of the last existing update on the timeline. Out-of-order timestamps are rejected with an error of the form `at must be greater than or equal to previous timeline update time ()`.
* **Edit a middle update**: the new timestamp must stay within the closed interval `[previous update's timestamp, next update's timestamp]` (both bounds inclusive).
* **Edit or delete the first update**: the event's `start_time` is automatically resynced to the timestamp of the new first update — no manual adjustment is required.
* **Editing an update vs. close time**: after an edit, the new `start_time` must not be later than the event's `close_time`; otherwise the update is rejected with `close_time must be greater than or equal to start_time` (for example, moving the first update of a scheduled maintenance past its planned end time).
* **Maintenance with auto-update by schedule**: if any of the above operations changes `start_time`, the pending auto-start job is rescheduled to align with the new start time.
### Close an event
Updating an event to a terminal status closes it:
* Incidents: Update status to **Resolved**
* Maintenance: Update status to **Completed**
When closing an event, the system automatically records the close time. All affected components must be in Operational status at this point.
### Reopen an event
Closed events can be reopened. Add a new timeline update with a non-terminal status to reactivate the event.
***
## Maintenance auto-scheduling
For maintenance events, you can set a **planned start time** and **planned end time**, and enable **auto-update by schedule**. The system will automatically advance the maintenance status at the specified times:
* **When the planned start time arrives**: Automatically updates status from Scheduled to Ongoing
* **When the planned end time arrives**: Automatically updates status from Ongoing to Completed
The auto-scheduled maintenance window cannot exceed **30 days**. If the planned end time is more than 30 days from now, the system will reject the creation.
### Manual override
Even with auto-scheduling enabled, you can manually update the maintenance status at any time:
* If you manually advance the maintenance to Ongoing, the system cancels the pending auto-start task
* If you manually mark the maintenance as Completed, the system cancels the pending auto-close task
When deleting a maintenance event with auto-scheduling enabled, the system automatically cancels all pending scheduled tasks.
***
## Retrospective events
When service status changes were not published in time, you can create a **retrospective event** to fill in historical records.
Retrospective events allow you to:
* Declare a past incident or maintenance
* Set precise start and end times
* Build the event timeline in actual chronological order
* Accurately associate affected components
Retrospective events are displayed on the status page in the same way as regular events and are included in event history and uptime calculations.
When creating a retrospective incident, the timeline must contain at least one update in a status other than **Resolved**, so the incident's progression can be presented.
If a retrospective event is created with a terminal status and no end time specified, the system automatically uses the timestamp of the last update as the end time.