For a handful of your own sites, a monitor is a scheduler, an HTTP client, a results table and an alert hook, and an agent writes that in one sitting; a Playwright script covers the click-through transaction checks. Pingdom's price goes to what a single machine can't fake: probes in several countries that agree an outage is real, SMS and email delivered by someone else's infrastructure, and a monitor that doesn't share a fate with the site it watches. Put the checker on a different provider, add a second small box as a second location, and the gap for personal use shrinks to SMS and real-user data.
Before you buildPingdom has no free plan, only a 14-day trial. If you just want uptime and a status page, Uptime Kuma is free and does it today; build your own only for the transaction checks and second-location logic.
Build me a self-hosted site monitor to replace Pingdom for my own websites. Requirements: - Node.js 22 + TypeScript: one Fastify process. `npm start` serves the admin on http://localhost:4880 and a read-only public status page at /status. A scheduler inside the process runs the checks. - Storage: better-sqlite3 in ./data/monitor.db: checks (name, URL, method, expected status, optional keyword that must appear, interval 1 or 5 minutes, timeout), results (time, ok, status code, milliseconds, error text) and incidents (check, started, ended). - Uptime check: an `undici` request per check. Retry once after 10 seconds before counting a failure; declare an outage after 2 failed runs in a row and recovery after 2 good ones. Warn when the TLS certificate expires within 14 days (read it with `node:tls`). - Transaction checks: each file in ./checks/*.spec.ts is a Playwright script (open a page, log in with credentials from .env, assert some text) run headless every 15 minutes; save a screenshot to ./data/shots on failure. - Alerts: email through nodemailer SMTP and a push message to an ntfy topic, both configured in .env, on outage and on recovery. No SMS. - Second location: `MODE=probe` runs the checks on another small server and POSTs the results to /api/ingest with a bearer token. A check only counts as down when this machine and the probe both fail. - Status page: current state per check, a 90-day strip of daily uptime percentages and the incident list. Admin: one password in .env (signed cookie) to add, pause and edit checks, with a response-time chart. - Single user. No accounts, no telemetry, local-first. Outbound calls: the URLs I monitor, SMTP, ntfy and the probe. - Out of scope: real user monitoring, SMS, a network of many regions, teams and roles. - README: running it under systemd or Docker, why it must live at a different provider than the sites it watches, and how to back up data/monitor.db.
Opens your agent with the prompt filled in, you press enter. Or copy it and paste it into an empty folder.
The first prompt builds the core. Run these one at a time in the same folder to grow it into your own Pingdom.
Add a Pingdom importer to the site monitor in this folder. Requirements: - A command `npm run import:pingdom` that reads PINGDOM_API_TOKEN from .env and lists the account's checks through the Pingdom API 3.1 (Bearer token); look up the checks endpoint in the OpenAPI spec downloaded from https://docs.pingdom.com/api/ and keep the spec in ./docs. - Map each HTTP check to a monitor check (URL, expected status, keyword, interval rounded to 1 or 5 minutes) and print the ones it cannot map, such as transaction and TCP checks. - Dry run by default; `--apply` writes the checks, skipping any URL that already exists. - Update the README.
Add page-speed tracking to the site monitor in this folder. Requirements: - Once a day per check flagged `speed`, run the `lighthouse` CLI in headless Chromium (mobile preset) and store the performance score, LCP, CLS and total byte weight in SQLite. - Show a 30-day chart per URL on the admin page and alert when the score drops 15 points below its 7-day average. - Cap it at 10 URLs and run them one after another, never in parallel. - Update the README with how much CPU a run uses.
Add a weekly report to the site monitor in this folder. Requirements: - Every Monday at 08:00 in the timezone from .env, email an HTML summary: uptime percentage per check for the last 7 days, number and length of incidents, slowest day and average response time. - Render the same report at /report/latest so it can be opened in a browser, and keep the last 12 reports. - Plain inline CSS only, so it looks right in common mail clients. - A `--send-now` flag for testing. - Update the README.
A monitor is only useful if it works on the day everything else is broken, so many teams prefer a service that lives on someone else's network and has a track record. Pingdom is a name that clients and managers already recognise, and the per-check plans are easy to expense. Moving existing checks, alert contacts and reports elsewhere is also a chore nobody schedules.
Estimate · A home server costs nothing; two small VPSes at different providers run about $8-10 a month. SMTP and ntfy fit free tiers. The build is token usage on your agent plan.
| Plan | Monthly | Annual, per month | What you get |
|---|---|---|---|
| Synthetic: 10 uptime + 1 advanced checks | $18 | $16.50 | 10 uptime checks, 1 advanced check, 50 SMS alerts, email alerting, maintenance windows, public status pages, unlimited users. |
| Synthetic: 25 uptime + 4 advanced checks | $40 | $36.33 | 25 uptime checks, 4 advanced checks, 100 SMS alerts. |
| Synthetic: 50 uptime + 10 advanced checks | $78 | $71.50 | 50 uptime checks, 10 advanced checks, 200 SMS alerts. |
| Real User Monitoring: 100,000 pageviews | $18 | $16.50 | 100,000 pageviews, unlimited sites and users, shareable reports, performance filtering, 13-month data retention. |
| Enterprise | custom | — | 500K to over 5M pageviews a month. |
Yes. An AI coding agent such as Claude Code, Codex or Cursor can build a usable personal version in one session with the prompt on this page, running on your own machine.
About $18 a month on the Synthetic Monitoring, smallest tier plan, $216 a year (checked 2026-10-20).
Probes spread over many countries that confirm an outage before alerting; SMS alerts through a carrier-grade gateway; Real User Monitoring: timings from your visitors' actual browsers; A hosted public status page that stays up when your own servers don't; Someone else keeping the monitor itself running at 3 a.m.. If any of those matter to you, keep paying.
Yes: Uptime Kuma (open source), Gatus (open source), Upptime (open source).