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's routes carry no auth extractor, so it is public wherever the binary runs, with a per-IP rate limit at the edge, 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

Run probe agents in the regions your users live in; the control plane assigns checks per region and the dashboard and status page can be viewed per-region. Bring your own agent anywhere — a single binary with an org-scoped token. See docs/multi-region.md.

_{Monitor detail — latency broken down by region}

Terraform

Manage targets and notification channels as code with the official provider uptimepage/uptimepage (source):

terraform {
  required_providers {
    uptimepage = {
      source = "uptimepage/uptimepage"
    }
  }
}

provider "uptimepage" {
  token = var.uptimepage_token # or set UPTIMEPAGE_TOKEN
  org   = "your-org-slug"      # required for managed resources; or UPTIMEPAGE_ORG
  # endpoint defaults to https://app.uptimepage.dev; set it for a self-hosted instance
}

resource "uptimepage_target" "api" {
  name     = "api prod"
  interval = 60
  check = {
    type = "http"
    http = {
      url             = "https://example.com/healthz"
      expected_status = { kind = "exact", exact = 200 }
    }
  }
}

MCP server

An MCP server lets an LLM client (the claude.ai connector, Claude Desktop, an IDE) answer questions about one org's monitors and take a few guarded actions, over Streamable HTTP at /mcp. Sixteen read-only tools plus fifteen write tools (each scope-gated, confirmed per action, and audited; a client that can't show a confirmation is offered the read tools only). Auth is an org-bound scoped token — paste one by hand, or use the one-click OAuth 2.1 connector. Off by default; enable with UPTIMEPAGE_MCP_ENABLED=true (+ MCP_OAUTH_ENABLED for the connector). See docs/mcp.md.

Self-host

Docker (recommended)

Three steps. No Rust toolchain and no compile step.

1. Start it

docker compose up -d

Pulls ghcr.io/uptimepage/uptimepage:latest and starts Postgres 18, ClickHouse 26.3, and the monitor. Both databases run their own migrations at startup, so there is nothing to wire up.

2. Create your account

docker compose exec uptimepage uptimepage bootstrap-owner --email you@example.com

Prints a one-time sign-in link, a full-access API token, and your org slug. These appear once, so copy them before closing the terminal.

3. Sign in and add a monitor

Open the link from step 2. That drops you into the dashboard at http://localhost:8080, where you can add your first monitor.

To stop: docker compose down, or docker compose down -v to delete the data too.

This stack has no TLS and no auth in front of it, and it publishes the database ports. Great for trying it out, not safe on the open internet. To run it for real, see Production deployment.

Options

Pin a version. Set UPTIMEPAGE_IMAGE=ghcr.io/uptimepage/uptimepage:1.3.0 to stay on a release instead of latest. Release tags carry no v prefix, though the git tag they are built from does.

On an ARM host? Release tags are linux/amd64 and linux/arm64. latest, which tracks the newest commit on main, is amd64 only, so pin a release on ARM.

Signing in later. The bootstrap link works once. For repeat sign-in, and to invite a team, set up OAuth with GitHub, GitLab, Google or Microsoft, or an email provider for magic links ([auth.github], [auth.gitlab], [auth.google], [auth.microsoft], [email] in config/default.toml, or the matching env vars). See docs/authentication.md.

Packaging this for an app store? Step 2 needs a terminal. Set UPTIMEPAGE_BOOTSTRAP__EMAIL instead and the first boot seeds that owner and logs a sign-in link, no shell required. See First-run owner.

curl -X POST http://127.0.0.1:8080/api/v1/targets \
  -H 'authorization: Bearer <token>' \
  -H 'x-uptimepage-org: <org-slug>' \
  -H 'content-type: application/json' \
  -d '{
    "name": "example",
    "check": {
      "type": "http",
      "url": "https://example.com/",
      "method": "GET",
      "timeout": 10000,
      "follow_redirects": false,
      "max_redirects": 0,
      "expected_status": { "kind": "exact", "value": 200 },
      "headers": {},
      "verify_tls": true
    },
    "interval": 180,
    "enabled": true,
    "tags": []
  }'

curl -H 'authorization: Bearer <token>' -H 'x-uptimepage-org: <org-slug>' \
  http://127.0.0.1:8080/api/v1/targets/<id>/uptime
curl http://127.0.0.1:9090/metrics

Production deployment

Anything reachable from the internet should run this stack, not the one above. It adds a Caddy edge with automatic TLS, internal-only Postgres and ClickHouse, per-IP rate limits, and blue/green restarts. The operator host is guarded by the app's own sign-in, not by an edge credential. It pulls the same published image. Setup runbook is in deployment/README.md, with the architecture in docs/deployment.md.

Kubernetes

kubectl create namespace uptimepage
kubectl -n uptimepage create secret generic uptimepage \
  --from-literal=fingerprint-salt="$(openssl rand -base64 32)" \
  --from-literal=credentials-kek-base64="$(openssl rand -base64 32)" \
  --from-literal=postgres-url='postgres://uptimepage:pw@pg.internal:5432/uptimepage?sslmode=require' \
  --from-literal=clickhouse-password='pw'

helm install uptimepage oci://ghcr.io/uptimepage/charts/uptimepage \
  --namespace uptimepage \
  --set domain=status.example.com \
  --set clickhouse.url=https://ch.internal:8443 \
  --set secrets.existingSecret=uptimepage \
  --set postgresql.existingSecret=uptimepage \
  --set clickhouse.existingSecret=uptimepage

Bring your own Postgres 18 and ClickHouse; the chart ships neither. A second chart, uptimepage-agent, runs a probe on its own in another region or inside a private network, against this or the hosted service. Details in docs/kubernetes.md and charts/.

Build from source

Published images are linux/amd64. Build from this checkout when you are on an ARM host (Apple silicon, Ampere), or when you are changing the code:

docker compose -f docker-compose.yml -f compose.build.yml up -d --build

Same stack and the same three steps as Docker, only the image origin differs. Note that your local build then owns that image tag, so run docker compose pull when you want the published image back.

Run without Docker

cargo build --release
./target/release/uptimepage

Requires Postgres and ClickHouse reachable at the URLs in config/default.toml, plus a non-empty fingerprint salt (the app refuses to boot without one):

export UPTIMEPAGE_AUTH__FINGERPRINT_SALT=$(openssl rand -base64 32)

To run against the compose stack without rebuilding the container:

docker compose up -d postgres clickhouse
cargo run --release

Docs

Hosted: https://uptimepage.dev/docs

Sources under docs/ — readable directly on GitHub too:

Web UI

The single binary serves both the /api/v1/* JSON surface and a server-rendered HTML UI at / — askama compile-time templates, HTMX for partial swaps and JSON forms (no SPA framework), Tailwind CSS 4, and lazy-loaded ECharts. Every UI mutation hits an existing /api/v1/* endpoint, so the API stays the single source of truth. Stack, routes, the add-a-page recipe, and UI tests are in docs/development.md.

Legal

A running instance serves its policies at /terms, /privacy, /cookies, /impressum, /abuse-policy, /security-policy, and an RFC 9116 /.well-known/security.txt. The source documents are in docs/legal/. GDPR self-service (data export, account deletion, recovery) lives under /settings/account.

License

uptimepage is licensed under AGPL-3.0. See LICENSING.md for what this means in practice.

If you'd like to contribute, see CONTRIBUTING.md. For security disclosures, see SECURITY.md.