Monitoring and status
Monitoring checks
Checks can originate from the platform or enrolled status agents.
#Overview
Checks can originate from the platform or enrolled status agents.
#Design a useful check
A check combines target, protocol, interval, success criteria, measurement source, and optional public visibility. Test configuration before enabling it.
Pause, resume, run, duplicate, and bulk actions change execution lifecycle. A manual run helps diagnosis but does not replace periodic history. Results from an older configuration version can be ignored.
#Create and validate
Choose a stable target and observable business criterion.
Select the platform or a compatible status agent as source.
Run the test and inspect latency, status, and message.
Enable the check, then define visibility and notification rules.
#Permissions by role
| Action | owner | admin | member | viewer |
|---|---|---|---|---|
| View checks, incidents, maintenance, and page | Read | Read | Read | Read |
| Create/run checks and manage incidents | Allowed | Allowed | Allowed | No |
| Manage channels, rules, and retries | Allowed | Allowed | No | No |
| Publish the page or enable/disable monitoring | Allowed | Allowed | No | No |
| Erase all monitoring data | Allowed | No | No | No |
#State lifecycle
| State | Meaning |
|---|---|
unknown | Not enough usable data yet. |
operational | Check is within expected thresholds. |
degraded | Partial degradation or warning threshold reached. |
outage | Significant failure under the check policy. |
maintenance | Result is inside a maintenance window. |
paused | Execution deliberately paused. |