Pingdom

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 the uptime monitoring that replaces Pingdom.

One rule dominates: **the monitor must not run where the thing being monitored runs.** Everything else is a loop with a timer.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker on a small server somewhere else entirely — a different provider, ideally a different country
- Caddy in front

THE DATA MODEL
- checks: id, name, kind, url, method, headers_json, body, expect_status, expect_body, interval_s, timeout_ms, regions_json, is_active
- results: id, check_id, region, at, ok, status, ms, error — **every check recorded, not only the failures**, so 'was it slow last Tuesday' is answerable
- incidents: id, check_id, opened_at, closed_at, cause, notified_at
- maintenance: id, check_id, from_utc, to_utc, note

CHECKING PROPERLY
- HTTP with a timeout, asserting the status and optionally a string in the body. **Asserting only the status misses the page that returns 200 with an error message on it**, which is the most common real outage
- Certificate expiry as its own check, alerting thirty days ahead
- DNS resolution and a TCP port check, which distinguish 'DNS is broken' from 'the app is down'
- Record the timing breakdown — resolve, connect, TLS, first byte — because 'slow' has four different causes and they need different people

MANY LOCATIONS WITHOUT MANY BILLS
- Two or three small servers in different regions and different providers. That is a few euros a month and it is the whole geographic argument
- **Confirm a failure from a second region before opening an incident.** One region failing is usually the network between there and you, and alerting on it is how monitoring gets ignored

TRANSACTION CHECKS
- A short scripted sequence — load, submit a form, assert the result — run less often than the simple checks because it is expensive
- Use a test account, never a real one, and **make it obvious in your own data that these requests are synthetic** so they do not pollute your analytics

ALERTING WITHOUT BEING HATED
- One incident per check, updated rather than repeated
- Escalation if unacknowledged; quiet hours with a severity override
- **Alert on recovery**, or somebody checks manually at three in the morning
- Maintenance windows that suppress alerts and are recorded in the history rather than hiding it

THE STATUS PAGE
- Static HTML on a different host and a different domain from the application. **A status page that goes down with the site is a status page that has never worked**
- Ninety days of history per check, and an honest uptime figure with the maintenance windows shown separately

WHAT MATTERS MOST
Running off-site, confirming from a second region, and a status page hosted elsewhere. Those three are the difference between monitoring and a comforting graph.