Repository navigation
docs: describe v3 status pages in the anatomy-of-a-status-page article (DOC-214) - #740
Merged
Merged
Conversation
…e (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 <noreply@anthropic.com>
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
hlenke
marked this pull request as ready for review
October 28, 2026 19:41
hlenke
enabled auto-merge
October 28, 2026 19:41
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes DOC-214.
The "Anatomy of a Status Page" article (copied unchanged from the old docs) said that Checkly status pages "classify alerts ahead of time into services", and linked to a
#servicessection that no longer exists. That describes the old v2 status pages. Since August 2026 customers get v3 status pages: new accounts only get v3, and existing accounts are asked to migrate (announcement).What changed: one sentence (line 60). It now says you organize each page into components, and that on Team and Enterprise plans automation rules match failing checks by tag and open an incident on the components you choose. Both links point to sections that exist. The rest of the author's article is general advice about status pages and stays as it is.
How it was proven: on a local Checkly stack (CLI 10.0.0), I deployed a v3 status page with two components ("Public API" and "Web app"), an automation rule for tag
doc214that targets "Public API", and a scheduled API check taggeddoc214that always fails.The plan note matches what the status pages overview and incidents pages already say. The proof resources were destroyed afterwards.
npm run check:linksand vale pass.Review: an independent reviewer confirmed the claims, the anchors, and that the rest of the article is generic advice and not wrong about Checkly. It suggested adding the plan note and saying "each page", because components belong to one page. Both are applied.
🤖 Generated with Claude Code