Skip to main content
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:

​
Maintenance

Maintenance represents a planned service change event used to notify users in advance of potential service impact. Maintenance has the following lifecycle statuses:

​
Publish an event

1

Select event type

In the status page management view, click Publish Event and choose either Incident or Maintenance.
2

Fill in event details

Configure the following fields:
3

Add an initial update

Every event requires at least one timeline update. The system automatically generates an initial update record based on the information you provide.
4

Publish the event

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:
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:
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 (<prev_at>).
  • 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.