> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/incidents-and-status-pages/status-updates.md). # Status updates A status update is the public half of an incident: the message your customers read, written deliberately and published when you decide. A status update is what your customers see. Everything else about an [incident](/incidents-and-status-pages/incidents.md) — its title, its summary, its severity, its timeline — is internal and stays that way. Nothing reaches a status page until somebody writes an update and publishes it. That gap is the point. It lets you mark a service degraded internally at 03:00 and decide what to tell the world at 03:20, once you know what is actually wrong. {% hint style="info" %} **Status updates were what ilert used to call "incidents".** The name **Incident** now means the [coordination record](/incidents-and-status-pages/incidents.md) your team works in. Your existing history was migrated and is intact. {% endhint %} ## Where an update goes An update carries one or more affected services, and those services decide its whole distribution: * it appears on **every status page** that contains at least one of them, * it notifies **subscribers** of those services and of those pages, * and it notifies anyone added as a **subscriber to the incident** itself. Pick no services and the update has nowhere to go. The dialog says as much. ## Post an update Status updates are posted from an incident, so the internal record and the public message stay attached to each other. Open the incident and click **Post status update**.

The ilert Post status update dialog: a Public title pre-filled from the incident, a Templates control, a Status segmented control set to Investigating, a Message box, an empty Affected services section, and a Notify subscribers toggle switched on. — **Notify subscribers** is on by default. The title is pre-filled from the incident but is a separate, public field.

| Field | What it does | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Public title** | The headline on your status pages. Pre-filled from the incident title, and shared by every update on this incident — changing it changes all of them | | **Templates** | Pre-fills the update from a saved [incident template](/incidents-and-status-pages/status-updates/incident-templates.md) | | **Status** | **Investigating**, **Identified**, **Monitoring**, or **Resolved**. This is the public status, and it is not the incident's own | | **Message** | The text customers read. [ilert AI](/incidents-and-status-pages/status-updates/ai-status-update-generation.md) can draft it | | **Affected services** | Which services this concerns, each with an impact level. The impact level is what sets the public status of that service | | **Notify subscribers about this status update** | On by default. Turn it off for a correction or a minor wording change that does not deserve everyone's inbox | Click **Publish update**. {% hint style="warning" %} **A service's public status changes only here.** Declaring an incident, or adding affected services to it, moves nothing on a status page. Some teams discover this the wrong way round — internally everything is marked degraded and the status page still says all is well. {% endhint %} ## Say it is over Post a final update with the status **Resolved**. The affected services go back to **Operational** on every page the update reaches, and subscribers are told the all-clear. You do not have to remember to do this separately: resolving the incident offers it as part of the [**Before you resolve**](/incidents-and-status-pages/incidents.md#resolving-an-incident) checklist, ticked by default whenever the incident has already posted an update. ## Automatically, from an alert An alert source can post a status update without anybody writing one, using an [incident template](/incidents-and-status-pages/status-updates/incident-templates.md) and the **Update status page** alert action. That is how a monitoring signal reaches a status page unattended. See [Services: automation with alert sources](/incidents-and-status-pages/services.md#automation-with-alert-sources). ## In this section


AI status update generation	Draft the message, and let ilert guess which services are affected.	AI status update generation
Incident templates	Saved wording for status updates, incidents, and maintenance windows.	Incident templates

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ilert.com/incidents-and-status-pages/status-updates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.