uptimepage

Status pages + uptime monitoring. Open source, free to start. Live in 5 minutes.

Monitor HTTP, TCP, ICMP ping, cron-job heartbeats, DNS, TLS-certificate and domain expiry, plus scripted browser login flows, from multiple regions — then turn green and red into a polished public status page your customers can subscribe to. Drive it by click, REST API, or Terraform. Self-host the single binary or use the hosted service.

Try it free →  ·  Docs  ·  Self-host  ·  Terraform  ·  MCP

Quick start

Hosted, no install:

1. Sign up at uptimepage.dev with GitHub, Google or your email address — no card.
2. Add a monitor: paste a URL, pick a check type and interval, save.
3. Bind a notification channel (Slack, email, PagerDuty, …) so failures reach you.
4. Turn on a public status page and share the link.

Prefer code? Drive the same account by REST API, Terraform, or MCP. Want to run it yourself? Go to Self-host.

Why uptimepage

Monitoring with a built-in status page isn't new — the bet here is doing it free, self-hostable, and fully as code:

• Free hosted tier, no card — and AGPL if you'd rather run it yourself.
• One self-contained binary — docker compose up and you're live, not a Kubernetes platform to operate.
• Everything as code — REST API, scoped tokens, an official Terraform provider, and an MCP server your LLM can query.
• Probes you own — run multi-region agents wherever your users are, on your own boxes.
• Status page + incidents + alerting in one — components, subscribers, and multi-channel paging that repeats until acknowledged, no second tool.
• Core isn't paywalled — checks, status pages, subscribers, the API and every alert channel are in the free tier.

Who it's for

• Founders / small SaaS — a professional status page in minutes, free, no self-host headache.
• Platform / SRE leads — monitors as code, multi-region probes, incident paging to your on-call channels, without vendor sprawl.
• Self-hosters — one binary plus two databases, no SaaS lock-in.

Live status

uptimepage monitors itself. These badges are served by the running app from a public status page — no third-party service, no cron job updating a JSON file.

Surface	HTTP	DNS	TLS cert	Domain
uptimepage.dev (website)
app.uptimepage.dev (dashboard)
mcp.uptimepage.dev (MCP)

Embed your own with the snippet in Settings → Pages → your page → Badge.

Features

Live service: https://uptimepage.dev — hosted, free, sign in with GitHub, Google or your email address. Full docs: https://uptimepage.dev/docs

_{Monitors — grouped by environment, filterable by type, tag, or owner}

Check types

tls_cert and domain_expiry use warn_days / critical_days thresholds and surface days_remaining plus registrar / cert subject in the result payload. Their floors are 1 hour for tls_cert and 12 hours for domain_expiry, regardless of plan — these probes track values that change on a scale of days, not minutes, and RDAP rate-limits by source address. flow runs a real browser, so it only executes where a browser engine is available (its regions clamp to the flow-capable set) and the number of flow monitors is capped per plan; put credentials in an org secret and reference them as {{name}}. Every flow run is kept with each step's outcome and duration, and the monitor page charts each step on its own scale, so a wait drifting from 200 ms to four seconds shows up long before the journey fails. A self-hosted install starts with that cap at 0; docs/monitor-types.md covers turning it on. See docs/api.md for the full payload shapes.

Public status page

A customer-facing /status page (HTML + JSON + RSS 2.0) is built into the binary. Per-target opt-in via public_status; the page bypasses basic auth at the Caddy layer with a per-IP rate limit, caches for 10 s in-process, and degrades gracefully if ClickHouse is unreachable. Operators narrate incidents (PATCH /api/v1/incidents/{id}, POST /api/v1/incidents/{id}/updates) and schedule maintenance windows (POST /api/v1/maintenance). Visitors subscribe for email or webhook updates. See docs/public-status.md.

_{Public status page — 90 days of history per component}

Alerting

Notification channels are per-org resources (Slack incoming webhook, generic HTTP webhook, Telegram bot, SMS gateway, …) created via /api/v1/notification-channels. Transport secrets are sealed at rest and never echoed back.

_{Alerting — Slack, PagerDuty, SMS, webhook, and seven more}

A target opts in by binding one or more channels in its alerts array:

"alerts": [
  { "channel_id": "0192…", "after_failures": 3 },
  { "channel_id": "0193…", "after_failures": 6, "notify_recovery": false }
]

Fire-once + recovery semantics. Channels are tenant-isolated — a target can only bind a channel its own org owns. See docs/api.md for the full contract.

_{Adding a channel — pick a transport, paste one credential}

Multi-region

Read the full README on GitHub →