# Timeline

The public record of how an event progressed.

Source: https://statusdashboard.com/docs/events/timeline

The timeline is the public record of status updates for incidents and maintenance events. Each entry captures a workflow phase, message, author, and timestamp, and appears on published status dashboards newest first.

***

## Adding a timeline entry
The timeline is the **public-facing record** of how an event progressed. It applies to **incidents and maintenance only** — informational events have no timeline.

Each timeline entry records:

* The current **status** — a phase from your incident or maintenance workflow
* A **message** explaining the current situation
* The **author** and **timestamp**

Entries are visible on published status dashboards, sorted newest first.

When you post a new timeline entry, you select a workflow phase and write a message. The event's current status updates to match that phase.

The timestamp defaults to **right now**. You can set a custom timestamp if you are recording an update that happened in the past — for example, if your team resolved the issue 15 minutes ago but you are only now posting the update. Custom timestamps must be in the past; future timestamps are not allowed.

## Re-opening an incident
When an incident reaches a **final** workflow phase (for example, *Resolved*), the platform sets its **end time** and marks it resolved.

If the issue **comes back** after you resolved it, use **Re-open Incident** on the **General** tab — do not post a new status from the **Timeline** tab.

### How to re-open
1. Open the resolved incident in the event editor.
2. Go to the **General** tab.
3. Choose **Re-open Incident**.
4. Select a **non-final** workflow phase (for example, *Investigating*).
5. Write a message explaining why the incident is being re-opened.

The platform then:

* Clears the resolved state and **end time**
* Sets the current status to the phase you selected
* Appends a new **timeline** entry with your message
* Returns the incident to your organization's **open incident** count

Resolved incidents show guidance on the **Timeline** tab instead of **Add Update**, so re-open always goes through the dedicated flow on General.

> Re-open is for 
>   **incidents only**
>   . Completed 
>   **maintenance**
>    events can still receive new timeline entries to move back to an active phase. See 
>   [Maintenance](/docs/events/types/maintenance)
>   .

### Notifications
If **Notifications** is enabled on the event, re-opening may enqueue subscriber notifications asynchronously — the same as other timeline updates. See [Notifications — What triggers a notification](/docs/events/notifications#what-triggers-a-notification) (**Reopen incident**).

## Editing a timeline entry
You can edit both the **message text** and **timestamp** of any timeline entry after it is posted. Edited entries are marked as "Edited" in the public timeline.

**For incidents, editing a timestamp cascades to the event itself:**

| Entry edited                                        | What else updates automatically          |
| --------------------------------------------------- | ---------------------------------------- |
| First entry (the initial status)                    | Incident `startTime` is updated to match |
| Last entry, when that entry is a final-phase status | Incident `endTime` is updated to match   |

This keeps incident **interval** times in sync with the timeline. If you correct a timestamp on the first or final entry, the corresponding event time updates automatically.

Editing a final entry’s timestamp does **not** change when the incident was marked complete for [Event History](/docs/status-dashboards/content/event-history) ordering. That moment is recorded separately when the event first enters a final phase.

## Deleting a timeline entry
You can delete any timeline entry that was posted in error. The event's current status, start time, and end time are **not affected** — those values are stored independently of the timeline. Deleting an entry only removes it from the visible history.

The **status label** of a posted entry cannot be changed directly. If you used the wrong label, delete the entry and post a new one with the correct label.

> **Public history:**
>    If your status dashboard was published when the entry was posted, your users will have seen it. Deleting it removes it from the timeline going forward but cannot undo what subscribers have already read. Use deletion to correct genuine mistakes, not to retroactively change the narrative.

## Initial timeline entry
When creating an **incident**, you provide an initial timeline message. Its timestamp is set to the incident's start time — the two are always in sync at creation.

When creating a **maintenance** event, you provide an initial timeline message timestamped to the current time.

## Overriding incident times directly
The **General** tab of an incident's edit form lets you set `startTime` and `endTime` directly. Use this as an escape hatch when you need to correct a time that the automatic sync did not get right — for example, after manually correcting a resolved entry.