> 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/getting-started.md). # Getting started Coordinate your response to an incident, and communicate it to the people who depend on you — while keeping the two apart. Two jobs run at once during an outage. **Coordinating** the response is internal, fast and messy. **Communicating** it is external, deliberate and slow. ilert keeps them separate on purpose, so nothing reaches your customers until you decide it should. ## Why it matters * Your responders work in one place instead of across a dozen noisy alerts. * Your customers hear something, which is what stops them opening tickets. * Nothing internal leaks by accident, because publishing is always a separate act. ## The building blocks * [**Services**](/incidents-and-status-pages/services.md) model the capabilities your users care about — Checkout, Search, Login. Everything else references them: alerts attach to them, incidents name them, status pages display them, and people subscribe to them. * [**Incidents**](/incidents-and-status-pages/incidents.md) are the coordination record for a significant event. Declaring one links the alerts, pages the responders, keeps the timeline, and runs the response to resolution. * [**Postmortems**](/incidents-and-status-pages/incidents/postmortems.md) are the write-up once the impact has ended: why the incident happened, and what stops it happening again. ilert AI can draft one from the incident for you to finish. * [**Status updates**](/incidents-and-status-pages/status-updates.md) are the public half. They appear on your status pages and reach subscribers. Until you post one, the incident appears on none of your status pages. * [**Status pages**](/incidents-and-status-pages/status-pages.md) are the public or private pages that show current service status and the history of what you have published. * [**Metrics**](/incidents-and-status-pages/metrics.md) put numbers next to those statuses, either posted by you or imported from Datadog or Prometheus. * [**Service topology**](/incidents-and-status-pages/service-topology.md) reconstructs how your services depend on one another from OpenTelemetry traces, so you can see the blast radius of a failure rather than guess it. ## How it fits together An [alert](/alerting/working-with-alerts.md) pages whoever is on call. If it turns into something that needs more than one person, you [declare an incident](/incidents-and-status-pages/incidents/declare-an-incident.md) — the internal hub where the team works the problem. Responders, the timeline and the [chat channel](/incidents-and-status-pages/incidents/incident-channels.md) all hang off the incident, not off the alert. If customers are affected, you [post a status update](/incidents-and-status-pages/status-updates.md) from that incident. Only then does the incident show on a [status page](/incidents-and-status-pages/status-pages.md), and only then are subscribers told. Internal detail stays internal; the public message is written on purpose. When the impact has ended, you write the [postmortem](/incidents-and-status-pages/incidents/postmortems.md) for that same incident. It stays internal unless you choose to show it on your status pages, and then only on the pages the incident already appeared on. --- # 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/getting-started.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.