Rank #5 of 5 in Incident Management & On-call
Access
Showcase


Try itExperimental
See what an agent can do with Better Stack before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si https://uptime.betterstack.com/api/v2/monitors | head -4recorded session — replayed, not liveVerified integrations
Connections to other tracked products — hover a chip for the verbatim evidence quote behind it.
By theme — the product's score on each story themeBy theme
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Ai incident — stories about ai incident in this arenaAi incidentevidence →
Stories about ai incident in this arena
Alerting escalation — stories about alerting escalation in this arenaAlerting escalationevidence →
Stories about alerting escalation in this arena
Analytics reliability — stories about analytics reliability in this arenaAnalytics reliabilityevidence →
Stories about analytics reliability in this arena
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Automation runbooks — stories about automation runbooks in this arenaAutomation runbooksevidence →
Stories about automation runbooks in this arena
Incident response — stories about incident response in this arenaIncident responseevidence →
Stories about incident response in this arena
Integrations observability — stories about integrations observability in this arenaIntegrations observabilityevidence →
Stories about integrations observability in this arena
Mobile experience — stories about mobile experience in this arenaMobile experienceevidence →
Stories about mobile experience in this arena
On call scheduling — stories about on call scheduling in this arenaOn call schedulingevidence →
Stories about on call scheduling in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Postmortems learning — stories about postmortems learning in this arenaPostmortems learningevidence →
Stories about postmortems learning in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Status communication — stories about status communication in this arenaStatus communicationevidence →
Stories about status communication in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where Better Stack stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓8/10
unlocks → Webhooks · Official SDKs · Machine-readable spec · Versioning policy · Official CLI · Full data export
Subscribe to events via webhooks
—0/10
Build against official SDKs
—0/10
Issue scoped/least-privilege API credentials for an agent
~3/10
Connect an agent via an official MCP server
✓7/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
n/an/a
Explore an interactive API reference with runnable examples
—0/10
Docs for agents
Point an agent at llms.txt or agent-oriented docs
~5/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
✓7/10
unlocks → MCP client
Operate the product with natural-language commands
✓7/10
Plug MCP servers into this product so it can use their tools
—0/10
Get AI-generated insights and suggestions from my data inside the product
✓7/10
Set up automations that run autonomously in the background
~6/10
Ai incident — stories about ai incident in this arenaAi incident
Stories about ai incident in this arena
Alerting escalation — stories about alerting escalation in this arenaAlerting escalation
Stories about alerting escalation in this arena
Escalation policies walk unacknowledged pages through multiple steps — delays, fallback responders, and repeat rounds — until someone acknowledges
✓9/10
Duplicate and related alerts are deduplicated and grouped so one incident pages one human, not fifty
—0/10
Pages reach me over the channels I choose — push, SMS, phone call, and email — with per-channel notification rules
✓9/10
Alerts from my monitoring tools are ingested through documented sources and routed to the right team by conditions I define
✓8/10
Analytics reliability — stories about analytics reliability in this arenaAnalytics reliability
Stories about analytics reliability in this arena
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Automation runbooks — stories about automation runbooks in this arenaAutomation runbooks
Stories about automation runbooks in this arena
Incident response — stories about incident response in this arenaIncident response
Stories about incident response in this arena
Internal stakeholders get structured incident updates they can subscribe to, without joining the war room
~6/10
Incidents carry defined roles (commander, comms lead) and task checklists so response stays coordinated under pressure
—0/10
Declare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me
~6/10
The incident timeline is captured automatically — alerts, actions, and chat decisions — and I can edit or annotate it afterwards
~5/10
Integrations observability — stories about integrations observability in this arenaIntegrations observability
Stories about integrations observability in this arena
Mobile experience — stories about mobile experience in this arenaMobile experience
Stories about mobile experience in this arena
On call scheduling — stories about on call scheduling in this arenaOn call scheduling
Stories about on call scheduling in this arena
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Postmortems learning — stories about postmortems learning in this arenaPostmortems learning
Stories about postmortems learning in this arena
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Status communication — stories about status communication in this arenaStatus communication
Stories about status communication in this arena
Sorted by importance (agentic first) (high → low) · 54/54 stories · click a row’s chevron for the rationale and evidence
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed⚿ | |
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 7/10 | Cclaimed | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 7/10 | Cclaimed | |
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Cclaimed | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Cclaimed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Cclaimed | |
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Tprobed | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Tprobed⚿ | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 3/10 | Cclaimed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ⚿ | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ⚿ | |
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ⚿ | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ⚿ | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | n/a | untested | none yet | |
Escalation policies walk unacknowledged pages through multiple steps — delays, fallback responders, and repeat rounds — until someone acknowledges C Escalation | sre | Alerting escalation — stories about alerting escalation in this arenaAlerting escalation | 3 | full | 9/10 | Cclaimed | |
Alerts from my monitoring tools are ingested through documented sources and routed to the right team by conditions I define C Routing | sre | Alerting escalation — stories about alerting escalation in this arenaAlerting escalation | 3 | full | 8/10 | Tprobed⚿ | |
Build on-call schedules with rotations, layers, time zones, and round-robin coverage that match how my teams actually work C Schedules | sre | On call scheduling — stories about on call scheduling in this arenaOn call scheduling | 3 | partial | 7/10 | Cclaimed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | partial | 7/10 | Cclaimed | |
Declare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me C Declaration | on-call engineer | Incident response — stories about incident response in this arenaIncident response | 3 | partial | 6/10 | Cclaimed | |
First-party integrations cover my observability stack — Datadog, Grafana, Prometheus, CloudWatch, Sentry — with documented setup C Alert sources | sre | Integrations observability — stories about integrations observability in this arenaIntegrations observability | 3 | partial | 6/10 | Cclaimed | |
My agent can acknowledge, escalate, and resolve incidents end to end through a documented API or MCP connection — no dashboard in the loop C Agent ops | ai-native user | Ai incident — stories about ai incident in this arenaAi incident | 3 | partial | 6/10 | Tprobed⚿ | |
AI writes the incident as it happens — live summaries, drafted updates, and scribed call notes — so responders respond instead of typing C Ai summaries | ai-native user | Ai incident — stories about ai incident in this arenaAi incident | 3 | partial | 5/10 | Cclaimed | |
Postmortems follow a real workflow — templates, drafting from the timeline, review, and publication G Postmortems | engineering leader | Postmortems learning — stories about postmortems learning in this arenaPostmortems learning | 3 | partial | 4/10 | Cclaimed | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | none | 0/10 | ⚿ | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | none | untested | none yet | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
Pages reach me over the channels I choose — push, SMS, phone call, and email — with per-channel notification rules C Paging | on-call engineer | Alerting escalation — stories about alerting escalation in this arenaAlerting escalation | 2 | full | 9/10 | Cclaimed | |
Publish a hosted public status page — custom domain, subscriber notifications — driven from incident state G Status pages | engineering leader | Status communication — stories about status communication in this arenaStatus communication | 2 | full | 9/10 | Cclaimed | |
Take an override, swap a shift, or request coverage without an admin rebuilding the schedule C Schedules | on-call engineer | On call scheduling — stories about on call scheduling in this arenaOn call scheduling | 2 | full | 8/10 | Cclaimed | |
An AI investigator digs into the probable cause — correlating changes, telemetry, and similar past incidents — before a human even asks C Ai investigation | ai-native user | Ai incident — stories about ai incident in this arenaAi incident | 2 | full | 7/10 | Cclaimed | |
A condition-based workflow engine automates the toil — updates, reminders, field changes — triggered by incident events C Workflows | sre | Automation runbooks — stories about automation runbooks in this arenaAutomation runbooks | 2 | partial | 6/10 | Cclaimed | |
AI drafts the postmortem from the incident record — timeline, contributing factors, follow-ups — ready for human review G Ai summaries | ai-native user | Ai incident — stories about ai incident in this arenaAi incident | 2 | partial | 6/10 | Cclaimed | |
A full mobile app lets me acknowledge, escalate, and resolve from my phone at 3am C Mobile | on-call engineer | Mobile experience — stories about mobile experience in this arenaMobile experience | 2 | partial | 5/10 | Cclaimed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 5/10 | Tprobed⚿ | |
Follow-up actions from incidents are tracked to completion and sync to our issue tracker C Follow ups | engineering leader | Postmortems learning — stories about postmortems learning in this arenaPostmortems learning | 2 | partial | 5/10 | Cclaimed | |
The incident timeline is captured automatically — alerts, actions, and chat decisions — and I can edit or annotate it afterwards C Timeline | sre | Incident response — stories about incident response in this arenaIncident response | 2 | partial | 5/10 | Cclaimed | |
Runbooks attach to incidents and their steps can trigger automatically — creating channels, assigning tasks, running diagnostics C Runbooks | sre | Automation runbooks — stories about automation runbooks in this arenaAutomation runbooks | 2 | partial | 4/10 | Cclaimed | |
The platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways C Workflow tools | sre | Integrations observability — stories about integrations observability in this arenaIntegrations observability | 2 | partial | 4/10 | Cclaimed | |
Duplicate and related alerts are deduplicated and grouped so one incident pages one human, not fifty C Noise reduction | sre | Alerting escalation — stories about alerting escalation in this arenaAlerting escalation | 2 | none | 0/10 | ||
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | 0/10 | ||
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | 0/10 | ||
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
I get reliability analytics — MTTA/MTTR trends, incident load, on-call health — to see whether we are actually improving C Metrics | engineering leader | Analytics reliability — stories about analytics reliability in this arenaAnalytics reliability | 2 | none | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | n/a | untested | none yet | |
Run private or internal status pages with access control for customer-specific or employee-only audiences G Status pages | engineering leader | Status communication — stories about status communication in this arenaStatus communication | 1 | full | 7/10 | Cclaimed | |
Internal stakeholders get structured incident updates they can subscribe to, without joining the war room C Communications | engineering leader | Incident response — stories about incident response in this arenaIncident response | 1 | partial | 6/10 | Cclaimed | |
My shifts sync to my personal calendar via a feed so I always know when I'm on the hook C Quality of life | on-call engineer | On call scheduling — stories about on call scheduling in this arenaOn call scheduling | 1 | partial | 6/10 | Cclaimed | |
Incidents carry defined roles (commander, comms lead) and task checklists so response stays coordinated under pressure C Coordination | engineering leader | Incident response — stories about incident response in this arenaIncident response | 1 | none | 0/10 | ||
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | n/a | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 38 stories with headroom
What would move Better Stack’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productPlug MCP servers into this product so it can use their tools
nonemoves agent-readyimpact 45
Better Stack ships its own MCP server so other agents (e.g.
Openness — open source, data portability, and self-hosting storiesExport all of my data in open formats and leave
nonemoves PA Scoreimpact 30
The evidence shows Better Stack offers APIs for managing monitors/incidents (e.g., Uptime API with bearer tokens) but nothing about bulk exporting logs, metrics, traces, or incident history in open formats, nor any stated data-portability policy for users who want to leave the platform.
Privacy posture — data-handling and privacy storiesPrevent my data from being used to train AI models
nonemoves PA Scoreimpact 30
The evidence pack contains no mention of AI training data opt-out, data usage policies for model training, or any privacy controls specific to preventing AI training on customer data.
Agenticness — how well agents can access and operate the productUse an official CLI
nonemoves agent-readyimpact 30
Evidence covers a REST API, MCP server, and Slack/Teams integrations, but there is no mention of an official CLI tool anywhere in the docs or probes.
Agenticness — how well agents can access and operate the productBuild against official SDKs
nonemoves agent-readyimpact 30
Evidence shows a documented REST API with bearer-token auth and an MCP server for LLM integration, but there is no mention of official client SDKs (e.g., Python, Node, Go libraries) for developers to build against.
Agenticness — how well agents can access and operate the productSubscribe to events via webhooks
nonemoves agent-readyimpact 30
Better Stack’s evidence pack covers Slack/Teams/email/SMS alerting, an API with bearer-token auth, and an MCP server for LLM workflows, but nowhere mentions webhooks as a subscription mechanism for events (incidents, monitor status changes, etc.).
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
Better Stack has documented REST APIs (Uptime API with bearer token auth) but there is no evidence of an interactive API reference with runnable/try-it examples — OpenAPI/Swagger endpoint probes all returned 404, and no docs mention an interactive console or code sandbox.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
Better Stack has a documented REST API (Uptime API with bearer-token auth) confirmed live via runtime probe, so a machine-readable spec is a fair expectation, but explicit probes for OpenAPI/Swagger files at all standard paths returned 404 and no docs mention an OpenAPI spec or downloadable schema.
Showing the top 8 of 38 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map8 surfaces · 33 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs22 stories
- Point an agent at llms.txt or agent-oriented docs
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Issue scoped/least-privilege API credentials for an agent
- Set up automations that run autonomously in the background
- My agent can acknowledge, escalate, and resolve incidents end to end through a documented API or MCP connection — no dashboard in the loop
- Escalation policies walk unacknowledged pages through multiple steps — delays, fallback responders, and repeat rounds — until someone acknowledges
- Pages reach me over the channels I choose — push, SMS, phone call, and email — with per-channel notification rules
- Alerts from my monitoring tools are ingested through documented sources and routed to the right team by conditions I define
- Define rules that trigger actions automatically on events
- Runbooks attach to incidents and their steps can trigger automatically — creating channels, assigning tasks, running diagnostics
- A condition-based workflow engine automates the toil — updates, reminders, field changes — triggered by incident events
- Internal stakeholders get structured incident updates they can subscribe to, without joining the war room
- Declare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me
- The incident timeline is captured automatically — alerts, actions, and chat decisions — and I can edit or annotate it afterwards
- The platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways
- A full mobile app lets me acknowledge, escalate, and resolve from my phone at 3am
- Build on-call schedules with rotations, layers, time zones, and round-robin coverage that match how my teams actually work
- Take an override, swap a shift, or request coverage without an admin rebuilding the schedule
- Do everything through the API that I can do in the UI
- Run private or internal status pages with access control for customer-specific or employee-only audiences
- Publish a hosted public status page — custom domain, subscriber notifications — driven from incident state
AI sre docs20 stories
- Run the product headlessly / in CI for automation
- Connect an agent via an official MCP server
- Drive the product through a documented public API
- Get AI-generated insights and suggestions from my data inside the product
- Set up automations that run autonomously in the background
- Delegate tasks to a built-in AI assistant inside the product
- Operate the product with natural-language commands
- My agent can acknowledge, escalate, and resolve incidents end to end through a documented API or MCP connection — no dashboard in the loop
- An AI investigator digs into the probable cause — correlating changes, telemetry, and similar past incidents — before a human even asks
- AI drafts the postmortem from the incident record — timeline, contributing factors, follow-ups — ready for human review
- AI writes the incident as it happens — live summaries, drafted updates, and scribed call notes — so responders respond instead of typing
- Define rules that trigger actions automatically on events
- Runbooks attach to incidents and their steps can trigger automatically — creating channels, assigning tasks, running diagnostics
- A condition-based workflow engine automates the toil — updates, reminders, field changes — triggered by incident events
- Internal stakeholders get structured incident updates they can subscribe to, without joining the war room
- Declare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me
- The incident timeline is captured automatically — alerts, actions, and chat decisions — and I can edit or annotate it afterwards
- The platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways
- Follow-up actions from incidents are tracked to completion and sync to our issue tracker
- Postmortems follow a real workflow — templates, drafting from the timeline, review, and publication
betterstack.com14 stories
- Run the product headlessly / in CI for automation
- Connect an agent via an official MCP server
- Drive the product through a documented public API
- Issue scoped/least-privilege API credentials for an agent
- Get AI-generated insights and suggestions from my data inside the product
- Set up automations that run autonomously in the background
- Delegate tasks to a built-in AI assistant inside the product
- An AI investigator digs into the probable cause — correlating changes, telemetry, and similar past incidents — before a human even asks
- Define rules that trigger actions automatically on events
- A condition-based workflow engine automates the toil — updates, reminders, field changes — triggered by incident events
- First-party integrations cover my observability stack — Datadog, Grafana, Prometheus, CloudWatch, Sentry — with documented setup
- The platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways
- A full mobile app lets me acknowledge, escalate, and resolve from my phone at 3am
- Follow-up actions from incidents are tracked to completion and sync to our issue tracker
Incident management docs9 stories
- Connect an agent via an official MCP server
- My agent can acknowledge, escalate, and resolve incidents end to end through a documented API or MCP connection — no dashboard in the loop
- Declare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me
- The incident timeline is captured automatically — alerts, actions, and chat decisions — and I can edit or annotate it afterwards
- First-party integrations cover my observability stack — Datadog, Grafana, Prometheus, CloudWatch, Sentry — with documented setup
- The platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways
- My shifts sync to my personal calendar via a feed so I always know when I'm on the hook
- Build on-call schedules with rotations, layers, time zones, and round-robin coverage that match how my teams actually work
- Take an override, swap a shift, or request coverage without an admin rebuilding the schedule
Uptime docs9 stories
- Set up automations that run autonomously in the background
- Escalation policies walk unacknowledged pages through multiple steps — delays, fallback responders, and repeat rounds — until someone acknowledges
- Pages reach me over the channels I choose — push, SMS, phone call, and email — with per-channel notification rules
- Alerts from my monitoring tools are ingested through documented sources and routed to the right team by conditions I define
- Define rules that trigger actions automatically on events
- A condition-based workflow engine automates the toil — updates, reminders, field changes — triggered by incident events
- Declare and run an incident from chat — Slack or Teams — with channels, roles, and updates created for me
- The platform integrates with the tools around the incident — Jira, Slack, Teams, Zoom, GitHub — so state flows both ways
- A full mobile app lets me acknowledge, escalate, and resolve from my phone at 3am
Status page docs5 stories
- Alerts from my monitoring tools are ingested through documented sources and routed to the right team by conditions I define
- Internal stakeholders get structured incident updates they can subscribe to, without joining the war room
- First-party integrations cover my observability stack — Datadog, Grafana, Prometheus, CloudWatch, Sentry — with documented setup
- Run private or internal status pages with access control for customer-specific or employee-only audiences
- Publish a hosted public status page — custom domain, subscriber notifications — driven from incident state
llms.txt2 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si https://uptime.betterstack.com/api/v2/monitors | head -4reproduced$ curl -si https://uptime.betterstack.com/api/v2/monitors | head -4 HTTP/2 401 date: Mon, 07 Sep 2026 05:12:18 GMT content-type: application/json; charset=utf-8 content-length: 166
Business model
Free tier (10 monitors, 1 status page, Slack/email alerts); incident management is $9/responder/month with per-user SSO add-ons, and telemetry (logs/metrics) is usage-priced — 60-day money-back guarantee.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
