Should I vibe code
A cron loop, a fetch, an alert webhook, and a status page
A cron, a fetch, a webhook and a status page. Genuinely a solved evening.
?
Their verdict, the price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
The classic starter project, and the homemade version is fine. Run it off-premises from what it monitors and add a second notification channel, because one channel is zero channels.
What actually breaks
not "if". the specific failures.
- Monitoring from one location, which cannot tell an outage apart from a network problem between you and the site
- The monitor running on the same infrastructure it watches, so a real outage silences the alarm
- Alert fatigue from a single failed check, which trains you to ignore the alerts that matter
- The status page being hosted with the thing it reports on, which is the classic and slightly embarrassing failure
- The alert path itself, which is never tested until the night it does not work
The server goes down at 02:40. So does the monitor, because it is a container on the same host — you put it there because that was where the deploy pipeline already ran. There is no alert, no incident, and the status page, served from the same machine, is also down and therefore says nothing at all. You find out at eight, from a user. Every component worked exactly as written. They just all shared a single point of failure, and it was the one being monitored.
Is that you?
the verdict is a default, not a law
- The monitor runs somewhere completely separate from what it watches
- The status page is static and hosted elsewhere again
- You alert on consecutive failures, not on one
- The monitor shares infrastructure with the target
- You have never tested that an alert actually reaches you
- A single failed request pages you
- Other people rely on your status page during an incident
If you build it anyway
the checklist, then the prompt that enforces it
- Run the monitor somewhere unrelated to the target. This is the whole design and everything else is detail.
- Require consecutive failures before alerting, and check from more than one location if you can, because one location cannot distinguish an outage from its own network.
- Host the status page as static files on separate infrastructure, so it survives the incident it describes.
- Test the alert path on a schedule — send a real alert monthly. An untested notification channel is not a notification channel.
- Alert on recovery too, so you know when to stop worrying without checking.
- Check for the right response, not just a 200 — a page that returns 200 with an error banner is still down.
Before you build uptime monitoring, apply these and push back if I ask you to break them.
1. Ask me where this will run, and refuse to put it on the same host, cluster
or provider region as the thing it monitors. Tell me the defining failure of
homemade monitoring is that the outage takes the monitor with it and nobody
is told.
2. Host the status page as static files on separate infrastructure again — a
different provider if possible. A status page that goes down with the
service is worse than none.
3. Require at least two or three consecutive failed checks before alerting, and
check from more than one location if available. A single failure from one
place cannot distinguish a real outage from my own network.
4. Verify the response content, not only the status code. Assert on an expected
string, because an error page can return 200.
5. Send a real test alert on a schedule — monthly — and record that it
arrived. An untested alert path is the second most common failure here.
6. Alert on recovery as well as failure.
7. Set a short timeout and treat a timeout as a failure, with the duration
recorded so slow degradation is visible before it becomes an outage.
8. Check certificate expiry as a separate alert with days of warning.
9. Keep an incident log so 'how often does this happen' is answerable.
10. Out of scope unless I ask: multi-tenant monitoring for other people,
on-call scheduling, escalation policies, SLA reporting.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
$30 a month buys checks from many locations, which is the one thing genuinely hard to replicate alone, plus an alert path somebody else tests. For a personal site, a cron on unrelated infrastructure is a solved evening — just do not run it next to the thing it watches.
Keep the check history as a simple exportable table — it is the only accumulating value, and it is what answers questions about reliability over time. Everything else is a cron, a fetch and a webhook, and is cheaper to rewrite than to migrate.
beloved self-hosted uptime monitor
Questions
Why does checking from one location matter?
Because a single vantage point cannot tell you whether the site is down or whether the path between you and it is. Routing problems, DNS issues and regional network faults all look identical to a total outage from one place — which means either you page yourself for other people's network problems, or you learn to ignore the alerts.
Is testing the alert path really necessary?
It is the difference between a monitor and the belief that you have one. Webhooks get revoked, phone numbers change, email routing rules quietly capture the alerts into a folder. None of that surfaces until an incident, and by then you are discovering two problems at once. A scheduled test alert costs nothing and turns the assumption into a fact.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice