> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/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 |
***
## Publish an event
In the status page management view, click **Publish Event** and choose either **Incident** or **Maintenance**.
Configure the following fields:
| Field | Description |
| ----------------------- | -------------------------------------------------------------------------- |
| **Title** | Brief title for the event |
| **Description** | Detailed description of the event |
| **Status** | Initial status of the event |
| **Affected components** | Select components affected by this event and set an impact status for each |
| **Responders** | Assign team members involved in handling the event |
| **Notify subscribers** | Whether to send notifications to subscribers when publishing |
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** 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.
***
## 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) |
| **Description** | Narrative text about the current progress |
| **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.
* **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.
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.