From cda964a0a006067935a1d3ea10be5515bc4044fc Mon Sep 17 00:00:00 2001 From: Hannes Lenke Date: Wed, 28 Oct 2026 15:28:46 -0400 Subject: [PATCH] docs: describe v3 status pages in the anatomy-of-a-status-page article (DOC-214) The article said Checkly status pages classify alerts into services and linked a #services anchor that no longer exists. Status pages are built from components, and automation rules match failing checks by tag and open incidents on chosen components. Verified on the local stack: a failing check tagged doc214 opened an incident with a partial outage on the rule's component only. Co-Authored-By: Claude Opus 5.5 --- learn/incidents/anatomy-of-a-status-page.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/learn/incidents/anatomy-of-a-status-page.mdx b/learn/incidents/anatomy-of-a-status-page.mdx index 902cfccf..a8e2e182 100644 --- a/learn/incidents/anatomy-of-a-status-page.mdx +++ b/learn/incidents/anatomy-of-a-status-page.mdx @@ -57,7 +57,7 @@ The basic technical requirements (fast loading pages, manual edits permitted, et **3. Clear infographics** - a status page should be able to take complex historical data and turn it into a clear history for the viewer. Some kind of graphing library should represent high level status data visually. -**4. Incidents should be organized into services** - for Checkly’s Status Pages, all alerts are [classified ahead of time into services](/communicate/status-pages/overview#services). We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services. +**4. Incidents should be organized into services** - for Checkly’s Status Pages, you organize each page into [components](/communicate/status-pages/overview#components) ahead of time, and on Team and Enterprise plans, [automation rules](/communicate/status-pages/overview#automatically-creating-incidents) match failing checks by tag and open an incident on the components you choose. We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services. **5. Subscription service** - Users should subscribe to only the pages they care about.