Better Stack On-Call — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Better Stack On-Call (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Better Stack Uptime includes integrated on-call scheduling that determines who gets paged when a monitor fails. Schedules define rotation patterns, and notification/escalation policies define how and when responders are alerted (via phone, SMS, email, or push). For MSPs, on-call is commonly configured per customer team, with separate schedules for each client's SLA requirements.
"escalation policy", and "paging" are shared vocabulary across all three products, and nothing in the phrasing disambiguates them. If the MSP's paging system is not Better Stack, use pagerduty-oncall or rootly-oncall.
rotation is not a service schedule; that lives in the PSA (autotask, halopsa, connectwise-psa).
betterstack-monitors.
Better Stack schedules define:
Policies define the alert cascade when a monitor goes down:
| Step | Description |
|---|---|
| 1 | Page the on-call schedule via phone, SMS, email, push |
| 2 (after timeout) | Escalate to a secondary schedule or individual |
| 3 (after timeout) | Escalate to team manager or broader group |
Better Stack calls these "notification policies" rather than "escalation policies", but they serve the same purpose.
Monitors are linked to notification policies at creation time. When a monitor goes down:
list_on_call_schedulesParameters:
per_page - Results per pagepage[after] - Pagination cursorget_on_call_scheduleParameters:
id - The schedule IDKey fields:
attributes.name - Schedule nameattributes.time_zone - Time zone (e.g., "America/New_York")attributes.current_shift - Current on-call user and shift endattributes.next_shift - Upcoming on-call user and shift startcreate_on_call_scheduleParameters:
name - Schedule name (required)time_zone - Time zone for the schedulelist_schedule_policiesParameters:
per_page - Results per pagelist_on_call_schedules to get all schedulesget_on_call_schedule for each relevant schedulecurrent_shift field -- shows who is currently on-call and when their shift endslist_schedule_policies to see all notification policiesBefore transitioning between on-call shifts:
list_incidents with status=acknowledged to find any open, active incidentsget_incident to get current statusget_monitor for the affected serviceacknowledge_incident if they are taking ownershipDuring planned maintenance:
pause_monitor to prevent false pages during the windowcreate_status_page_incident for customer-facing workresume_monitor on all paused monitorslist_incidentsCause: Invalid schedule ID or schedule was deleted Solution: List schedules to verify the correct ID
Cause: Invalid time zone format or member IDs Solution: Verify time zone format and confirm member IDs exist
Cause: Schedule has no on-call user for the current time Solution: Check schedule configuration and ensure rotations cover all time periods
current_shift before major changes to confirm the right person is on-call~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.