Add status page guide and IncidentTrigger construct documentation#162
Add status page guide and IncidentTrigger construct documentation#162stefanjudis merged 5 commits intomainfrom
Conversation
| | `testOnly` | `boolean` | ❌ | `false` | Only run with test, not during deploy | | ||
| | `retryStrategy` | `RetryStrategy` | ❌ | - | Strategy for configuring retries | | ||
| | `runParallel` | `boolean` | ❌ | `false` | Run monitors in parallel or round-robin | | ||
| | `triggerIncident` | `IncidentTrigger` | ❌ | - | Create and resolve an incident based on its alert configuration | |
There was a problem hiding this comment.
Can you clarify what "its" is referring to here because I'm not sure it's correct the way I understand it?
There was a problem hiding this comment.
This is 1:1 from the typescript docs. :D I'll fix them both then. :D
There was a problem hiding this comment.
Fair enough, I think it should say "check's" or "monitor's" alert configuration.
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive documentation for status page incident automation, enabling users to connect synthetic monitoring to status pages for user-facing availability communication.
Changes:
- New guide explaining how to use Checkly status pages with synthetic monitoring to reflect actual user experience rather than infrastructure health
- New IncidentTrigger construct documentation for automating status page incidents based on check failures
- Added
triggerIncidentoption to general monitor options and fixed mislabeled tab in Playwright Check construct docs
Reviewed changes
Copilot reviewed 6 out of 10 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
guides/communicate-availability.mdx |
New comprehensive guide on connecting status pages to synthetic monitors for user-experience-driven availability reporting |
constructs/incident-trigger.mdx |
New reference documentation for the IncidentTrigger construct with configuration options and examples |
snippets/general-monitor-options-table.mdx |
Added triggerIncident option to the general monitor options table |
constructs/playwright-check.mdx |
Fixed tab label from "URL Monitor" to "Playwright Check Suite" |
docs.json |
Added new guide and construct pages to navigation structure |
guides/startup-guide-detect-communicate-resolve.mdx |
Removed trailing whitespace (formatting cleanup) |
images/guides/images/status-pages-user-behavior-*.png |
Added 4 new screenshots illustrating the status page setup workflow |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
constructs/incident-trigger.mdx
Outdated
| @@ -0,0 +1,155 @@ | |||
| --- | |||
| title: 'IncidentTrigger Construct' | |||
There was a problem hiding this comment.
Hmm, I wouldn't call IncidentTrigger a construct. A construct in the CLI is typically something that by itself creates an actual resource behind the scenes. Simply defining an IncidentTrigger does not do that - it's just a regular JS object. When the object is attached to a check, then it becomes part of the check construct's properties. But IncidentTrigger by itself is not a construct.
There was a problem hiding this comment.
Yeah... I thought about that already but went with "it's fine". IncidentTrigger docs clearly belong next to the constructs which live under /constructs.
On the other hand we are also a bit on a stretch with /constructs/project. I'm more than open for suggestions here. :)
There was a problem hiding this comment.
Maybe "IncidentTrigger Configuration" and "Project configuration"? 🤔
There was a problem hiding this comment.
Akshually Project IS a construct. It has slightly special behavior compared to the other ones but it functions more or less the same as the other constructs, and inherits from Construct too.
There was a problem hiding this comment.
Ok. Then here's the proposal. Incident Trigger stays where it is but we'll call it "Incident Trigger Configuration". Deal? :D
sorccu
left a comment
sorccu
left a comment
There was a problem hiding this comment.
I read the pages and they look good to me.
I had a couple of minor comments that would be nice to address. I have no other comments.
thebiglabasky
left a comment
thebiglabasky
left a comment
There was a problem hiding this comment.
Looks good. Made some non-blocking suggestions
|
|
||
| ### Create services that match user expectations | ||
|
|
||
| Services should reflect how users perceive your application. Users care about "Login" working, not whether your auth microservice cluster is healthy. |
There was a problem hiding this comment.
There's also a place in the docs section where we mention that. That's good to reiterate here, but I wonder if then we could trim off the docs part to link here instead? This guide is much more comprehensive. Or maybe just add a link to this guide from the docs as a "Learn more" (I probably like that best)
There was a problem hiding this comment.
Copy that! Added!
|
|
||
|  | ||
|
|
||
| ### Connect synthetic monitors to services |
There was a problem hiding this comment.
We should point out that this is a paid feature (maybe a note or so after the steps?)
Co-authored-by: Hervé Labas <431257+thebiglabasky@users.noreply.github.com>
|
@thebiglabasky @sorccu Thanks for the great review. I addressed the changes and am going in! 🙇 |
3 participants
Affected Components
Notes for the Reviewer
New content
guides/communicate-availability.mdx- Explains how Checkly status pages reflect actual user experience through synthetic monitoring rather than arbitrary infrastructure metricsconstructs/incident-trigger.mdx- Reference documentation for the IncidentTrigger construct (automating status page incidents based on check failures)Fixes & updates
constructs/playwright-check.mdx- Fixed mislabeled tab from "URL Monitor" to "Playwright Check Suite"snippets/general-monitor-options-table.mdx- Added missingtriggerIncidentoptiondocs.json- Added new pages to navigationNew Dependency Submission
None
Screenshots