Connect monitoring to the tools you already run.

Alerting channels

Ten channels, none of them tier-gated. Operator email goes out automatically on every down and recovery transition. On top of it you can add Slack, a signed outgoing webhook, PagerDuty, Discord, Microsoft Teams, Opsgenie, incident.io, FireHydrant, and a Zapier or generic JSON hook, each configured from the dashboard's Notifications section and each delivered in that service's own format. Every channel fires on the same transitions and respects the same scheduled-maintenance suppression, and every one can be test-sent before you depend on it. Free accounts can hold 5 channels at once, Growth 25, and Scale 150.

On Growth and Scale, escalation policies put those channels in an ordered chain: an alert nobody acknowledges moves to the next person, rotation, or channel after a delay you set. Opsgenie and PagerDuty steps open their own alert under an escalation key, so acknowledging in RealUptime does not close it there. There is no native SMS or phone-call paging; route through PagerDuty or Opsgenie to make a phone ring. See alerting and on-call for the per-channel setup, and the API reference for the webhook payload shape, signature verification, and PagerDuty's event mapping.

Status page badge and embed

Every status page can generate a live uptime badge (an SVG image) and an embeddable status card (an iframe) from the dashboard, ready to drop into a README, a docs site, or your own homepage. Both reflect the same real-time status your public status page shows.

Programmatic access

The REST API and the MCP server expose the same nine operations against the same data: list and create monitors, read a monitor's live status, update which regions probe it, remove it, list your status pages, list recent incidents, and open or update incidents. Both use the same bearer API key, generated from the dashboard's API & MCP access section. The REST API is gated to Growth and Scale plans. The MCP server is available on every plan for read-only operations (list monitors, read status, list incidents); write operations (create, update, delete monitors, and open or update incidents) require Growth or Scale. Read the full API reference or the MCP server docs for setup, authentication, permission scopes, and rate limits.

GitHub Action

A plain curl step against the REST API's read endpoints, dropped into a single workflow step: check one or more monitors and fail the run (or just report outputs) if any of them is down or degraded. Useful as a post-deploy gate, or anywhere a workflow needs to confirm a dependency is actually healthy before continuing. See the GitHub Action docs for the copy-paste steps.