Hyperping

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me uptime monitoring with a status page that replaces Hyperping: checks from more than one place, and a page that stays up when I do not.

STACK
- Node 20+ with Fastify for the control plane
- SQLite through better-sqlite3, WAL mode
- Probes as small agents polling for work, one per region — a second region is one more cheap VPS somewhere else
- Caddy in front

THE DATA MODEL
- monitors: id, name, kind, target, method, headers_json, body, expected_status, expected_body, interval_seconds, timeout_ms, regions_json, degraded_ms, confirmations_required, is_active, muted_until
- checks: id, monitor_id, region, status, response_ms, status_code, error_kind, error_message, tls_expires_at, checked_at — append-only, and the whole archive
- incidents: id, monitor_id, opened_at, closed_at, cause_check_id, regions_json, is_confirmed, notified_at
- status_pages: id, slug, name, custom_domain, logo_path, accent, is_public, password_hash
- components: id, status_page_id, name, description, position, group_name; component_monitors: component_id, monitor_id
- announcements: id, status_page_id, kind, title, status, started_at, resolved_at, affected_components_json — maintenance and incidents written by hand
- announcement_updates: id, announcement_id, body_md, status, at — the update history, append-only
- subscribers: id, status_page_id, kind, target, token, confirmed_at, unsubscribed_at, components_json

CHECKS
- HTTP with a method, headers, a body, an expected status and an optional expected string or JSON path in the response
- TCP, ICMP where the host allows it, DNS resolution, and TLS certificate expiry as its own check
- A keyword check that fails when a string is present, which is how you catch an error page returning 200
- Response time recorded on every check, and a degraded threshold separate from the timeout so 'still up, three times slower' is visible

MORE THAN ONE PLACE, WHICH IS THE WHOLE POINT
- Each probe has a region name and a token, long-polls for work, and posts results back
- A failure from one region is a network event; a failure confirmed from N regions is an outage. Nothing opens an incident until the confirmation threshold is met, and the threshold is per monitor
- The failing check is repeated immediately from a different region before anything is declared, because the cheapest way to avoid a false alarm is to look again
- Probe health monitored: a region that stops reporting is itself an alert, not silence
- The control plane never runs checks, so the machine that decides is never the machine that is busy

THE STATUS PAGE
- Its own subdomain or a custom domain with on-demand TLS, and an allowed-host check against the database before requesting a certificate
- Components grouped, each showing current state and 90 days of history as a bar per day, computed from checks at query time
- Uptime percentage with its window and its definition written next to it. Everybody computes uptime differently and a number without a definition is decoration
- Incidents with a written update history — investigating, identified, monitoring, resolved — and scheduled maintenance announced in advance
- Subscribers by email, webhook and RSS, per component, with confirmation and one-click unsubscribe
- Fast, server-rendered, no framework. This page is loaded by everybody at once, precisely when things are going wrong

WHERE IT LIVES, WHICH IS THE PART THAT MATTERS
- The status page must not run on the infrastructure it reports on. Different machine, different provider, different network — otherwise the outage takes the page with it and the page's only job is to work on the worst day
- Say this in the README as the first deployment instruction, not as a footnote
- The page serves from a cache that survives the control plane being unreachable, showing the last known state with its timestamp rather than an error

ALERTING
- Escalation after N confirmed failures, channels for email, webhook, chat and a shell command
- Recovery notifications always, in the same channel
- Muting with an end time, never indefinitely
- A maintenance window suppresses alerts and says so on the page

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, PROBE_TOKEN_SALT, SMTP_URL, SESSION_SECRET
- Migrations on boot, each once
- Checks pruned to per-hour summaries after a stated window, computed from the rows before they go
- Nightly backup off the machine, restore script
- Health endpoint reporting every probe's last contact

WHAT MATTERS MOST
Multi-region confirmation and where the page is hosted. Build the confirmation rule first — a monitor that pages you for one region's packet loss gets muted, and a muted monitor is worse than none — and deploy the status page somewhere else entirely before you deploy anything else.

Give me the repository, the probe agent, migrations, .env.example, and a README with deploy steps for the control plane, a second region, and the status page on separate infrastructure.