UptimeRobot

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 that replaces UptimeRobot — and put it somewhere that is not my own infrastructure, which is the only rule that matters.

Read this first: a monitor that runs on the machine it watches tells you nothing, because when the machine dies so does the monitor. Rent the cheapest virtual machine you can find, at a different provider, in a different network, and run this there. That single decision is most of the product.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A scheduler in its own process
- Caddy in front, and the whole thing small enough for the smallest instance available
- Optional extra probes: the same agent, on two more cheap machines elsewhere

THE DATA MODEL
- monitors: id, name, kind, target, method, headers_json, body, expected_status, expected_body, keyword_absent, interval_seconds, timeout_ms, regions_json, confirmations_required, degraded_ms, is_active, muted_until, tags_json
- checks: id, monitor_id, region, status, response_ms, dns_ms, connect_ms, tls_ms, ttfb_ms, status_code, error_kind, error_message, tls_expires_at, checked_at — append-only
- incidents: id, monitor_id, opened_at, closed_at, cause_check_id, regions_json, confirmed_at
- alerts: id, incident_id, channel, target, sent_at, acknowledged_at, error
- maintenance: id, monitor_id, starts_at, ends_at, note
- status_pages, components, subscribers — the same shape as any status page, served statically
- Checks kept in full for a window and then reduced to hourly summaries computed from the rows before they are pruned

CHECK KINDS
- HTTP with a method, headers, a body and assertions on status, a string present, a string absent, or a JSON path. The absent-string check is what catches an error page returning 200, which is the outage nobody notices
- TCP for a port, ICMP where the host allows it, DNS resolution against an expected answer
- TLS certificate expiry as its own check, warning weeks in advance. An expired certificate is an outage you scheduled for yourself
- Timing split into DNS, connect, TLS and time to first byte, because 'it is slow' is not actionable and 'TLS takes two seconds' is

NOT CRYING WOLF
- Confirm before opening an incident: N consecutive failures, and where there is more than one probe, agreement from more than one
- Re-check immediately from a different place before declaring anything. Looking again is the cheapest false-alarm prevention there is
- A degraded threshold separate from the timeout, so slow is a state rather than silence
- Flapping suppressed: repeated failure and recovery produces one incident, not twenty
- Alert on recovery too, always, in the same channel
- Muting always has an end time. An indefinitely muted monitor is a monitor that has been quietly deleted

ALERTS
- Email, webhook, chat, and a shell command for anything else
- Escalation to a second target after N minutes unacknowledged, with acknowledgement from a link in the alert that needs no login
- Quiet hours per monitor, with a severity that ignores them
- One alert per incident, not one per failed check
- The alert path must not depend on the thing being watched. If it emails through your own mail server, and your own mail server is what is down, you will hear nothing — use a different provider for alerts and say so in the README

THE STATUS PAGE
- Components mapped to monitors, 90 days of history, uptime with its window and definition written beside it
- Incidents with a written update history, and maintenance announced in advance
- Rendered as static files on every change, so it serves even if the application is not running
- Subscribers by email, webhook and RSS, per component, with one-click unsubscribe

BEING SMALL
- The whole point is that this runs on the cheapest machine available. One process, one SQLite file, no browser, no queue system
- A hundred monitors on a one-minute interval is a hundred requests a minute, which is nothing. Do not build for a scale you do not have
- The scheduler reads due monitors, fires them with a concurrency cap, and records the results. That is the loop

WATCHING THE WATCHER
- A dead-man's switch: the scheduler pings a free external service on every tick, and that service alerts if the pings stop. Otherwise a crashed monitor looks exactly like a healthy site
- Disk and memory checked, and the database pruned on a schedule

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SMTP_URL, SESSION_SECRET, DEADMAN_URL, PROBE_TOKEN_SALT
- Migrations on boot, each once
- Nightly backup off the machine — a small one, since the value is the incident history rather than the checks
- Health endpoint reporting the scheduler's last tick and every probe's last contact

WHAT MATTERS MOST
Where it runs and the dead-man's switch. Deploy it somewhere unrelated to what it watches, make the alert path independent too, and set up the external check on the checker before you rely on any of it.

Give me the repository, the scheduler, the probe agent, the static status page, migrations, .env.example, and a README whose first section is where to deploy it.