checkly constructs
The Checkly constructs system provides type-safe abstractions for monitoring resources.
Core concepts
Construct hierarchy
Construct (base)
├── Check
│ ├── RuntimeCheck
│ │ ├── ApiCheck
│ │ ├── BrowserCheck
│ │ └── MultiStepCheck
│ └── PlaywrightCheck
├── Monitor
│ ├── HeartbeatMonitor
│ ├── TcpMonitor
│ ├── DnsMonitor
│ └── UrlMonitor
├── CheckGroup
└── AlertChannel
Logical IDs
Every construct needs a unique logical ID:
new ApiCheck('api-status-check', { // <- logical ID
name: 'API Status Check', // <- display name
})
Rules:
- Must be unique within resource type
- Pattern:
[A-Za-z0-9_-/#.]+ - Use descriptive IDs:
'homepage-check'not'check-1'
Construct lifecycle
- Construction: Instance created and registered
- Validation: Configuration checked for errors
- Bundling: Code and dependencies packaged
- Synthesis: Converted to API payload
- Deployment: Created/updated in Checkly
Session and Project
The Session singleton manages global state:
// Internal - you don't normally interact with this
Session.current().addConstruct(check)
The Project aggregates all constructs:
// Internal - happens automatically
project.addResource('check', check)
Configuration inheritance
// checkly.config.ts - global
checks: {
frequency: 10,
locations: ['us-east-1'],
}
// CheckGroup - group-level
const group = new CheckGroup('api', {
frequency: 5, // Overrides global
})
// Check - check-level
new ApiCheck('critical-api', {
group: group,
frequency: 1, // Overrides group
})
Related Skills
- See
checkly-checksfor practical check creation - See
checkly-groupsfor organization