Should I vibe code
Run scheduled API and browser checks from one independent worker
A monitor that is down and a service that is up send exactly the same alert: none.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A cron that curls an endpoint and posts to Slack is twenty minutes, and it will make you feel monitored for about a month. Two things then undo it. The worker almost always ends up in the same account, region or cluster as the thing it watches, so the outage that matters is the one it cannot report. And browser checks — the half of Checkly that is not trivial — hold real login credentials and break on every selector you rename, which trains you to ignore the alerts you built the whole thing to receive. What you cannot generate is independence, and independence is the product.
What actually breaks
not "if". the specific failures.
- The monitor sharing a provider, region or network path with the thing it monitors, so the real outage produces silence rather than a page
- Silence being indistinguishable from health — nothing tells you the scheduler stopped firing three weeks ago
- Browser checks failing on a selector you renamed, which reads as an outage and teaches you to dismiss the alert without reading it
- One worker in one location, so a local DNS blip is reported as a global outage and a regional outage is reported as nothing at all
- Real credentials for a real account sitting inside check definitions, on a box you patched once, so a login check is a stored password with a cron attached
- Alerts delivered through the same email or chat provider you would also lose during a broad enough incident
- Retention, because the value of a monitor is the history and a SQLite file that grows every sixty seconds eventually stops being queryable
Is that you?
the verdict is a default, not a law
- It runs somewhere your production stack does not — different provider, different account, different credit card
- The checks are unauthenticated GETs against public endpoints, so nothing sensitive is stored to make them work
- You have a dead-man's switch that pages you when the monitor itself stops reporting
- It is a personal project and a missed alert costs you an apology
- It lives in the same account, region or cluster as the thing it watches
- Browser checks hold credentials for an account with any privilege beyond read
- A missed page costs a customer money or triggers an SLA credit
- Nobody is on the hook for keeping the checks green, so the dashboard is amber and has been for months
If you build it anyway
the checklist, then the prompt that enforces it
- Host the monitor somewhere with no shared dependency on the target — different provider, ideally a different DNS resolver and a different payment method.
- Build the heartbeat before the first check. The monitor pings an external dead-man's-switch on every cycle, and that service pages you when the pings stop.
- Use a dedicated, least-privilege account for authenticated checks, credentials from a secret store, rotated. Never your own login.
- Require N consecutive failures from more than one vantage point before paging. A single failed request is weather.
- Alert through a channel with a different failure domain from your product, and test it deliberately on a schedule rather than during an incident.
- Keep check definitions in version control as code, so a check that has been failing since March is visible in a diff rather than only in a UI nobody opens.
- Set retention and roll up old results. A results table that only grows turns your monitor into the next thing that runs out of disk.
I am building my own uptime and synthetic monitoring. The failure
mode here is silence rather than noise, so order the work accordingly and argue
with me if I ask for the dashboard first.
1. Start by telling me what this shares with the thing it monitors — provider,
region, DNS, account, billing. Every shared dependency is an outage class
this tool cannot report. List them explicitly.
2. Build the heartbeat before the first check: every scheduler cycle pings an
external dead-man's switch, and that service pages me when the pings stop.
Without it, a crashed monitor and a healthy service look identical.
3. Then build alert delivery, and make me test it. A monitoring system whose
alert path has never fired is a dashboard.
4. Only then write checks, starting with unauthenticated GETs against public
endpoints. Do not introduce credentials until I ask.
5. When I ask for authenticated or browser checks: a dedicated least-privilege
account, credentials from a secret store and never from the check definition,
and tell me plainly that this box now holds a working production login.
6. Require N consecutive failures from at least two vantage points before
alerting. A flapping check is worse than no check — it trains me to ignore
the alert I built the whole thing to receive.
7. Record every result with timestamp, latency, status and vantage point, and
give me retention with rollups from day one.
8. Keep check definitions as code in the repo, so a check that has been red
since March shows up in a diff rather than only in a UI nobody opens.
9. Timeouts everywhere, and a cap on concurrent checks. A monitor hammering a
struggling service during an incident is part of the incident.
10. In the README write "What this cannot tell me": the outage classes that take
the monitor down along with the target.
11. Out of scope, and say so: status pages, on-call rotation, escalation. If I
want a pager, tell me the hosted product is $39 a month.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Once anyone else notices the downtime before you do. $39/month buys checks running from locations you do not operate, on infrastructure that cannot fail with yours, plus the browser-runner upgrades you would otherwise chase every time Chrome moves. If the monitoring itself is the fun part, self-host Uptime Kuma and put the heartbeat somewhere else.
$39/mo is cheaper than your weekend.
Keep checks as code and results as boring rows — url, assertion, timestamp, latency, status. Every hosted monitor imports that shape or does not need it, so the migration is an afternoon. The thing that does not migrate is the alerting muscle memory: cut over with both running for a fortnight, because the first week on a new pager is when you find out which alerts were never firing.
Popular open-source uptime monitoring dashboard with many check types.
Questions
Isn't a cron job with curl genuinely enough?
For a personal site, yes, and that is a legitimate ship-it. It stops being enough at the point you would be upset to learn about an outage from a customer — because a cron job cannot tell you it stopped running. Add the external heartbeat and you have covered the single biggest gap for about a minute of work.
What actually makes browser checks harder than API checks?
They are a real browser you now operate. Headless Chrome updates, fonts and rendering differences change screenshots, selectors move whenever the frontend does, and the check needs a working login for your own product. An API check is a request and an assertion. A browser check is a test suite with a credential, and test suites rot.
Where should the monitor run, then?
Anywhere your product does not. A different cloud, a different account, ideally a different card — because a billing failure that takes down your app should not also take down the thing that tells you your app is down. A small box at a second provider plus an external dead-man's switch covers most of the realistic failures.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your error logs are the least-secured copy of your most-sensitive data.
A cron, a fetch, a webhook and a status page. Genuinely a solved evening.
Your log store is an unaudited second copy of every secret your application has ever handled.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice