5 DIY AI website monitors and why we’d still use StatusCake

Getting Claude to write a website monitor is the easy bit. Ask it to check a URL and send you a Slack message when something goes wrong. Run it against a broken URL and you might get that first alert before you’ve finished your coffee.

Now give it 100 URLs to check every minute. Ask it to warn you before your domains or certificates expire, catch SSL errors and tell you when checkout starts taking eight seconds to load. Then see what happens when a bunch of those checks time out at once.

That’s the comparison we wanted to make. StatusCake Superior costs $20.41 a month when billed annually. Here’s what we priced up for the DIY setups, using Superior’s allowances and check intervals for these four types of monitoring.

What you’re monitoring	How many	How often
Website and endpoint uptime	100	Every minute
Domain expiry	50	Every 7 days
SSL expiry and certificate errors	50	Every 30 minutes
Page speed	15	Every 15 minutes

That’s 4.32 million scheduled uptime checks and 43,200 browser runs in 30 days, before retries or confirmation checks. For the cloud examples, we’ve budgeted $12 per server running uptime checks and $24 for a separate server running the browser tests. Those are starting estimates in US dollars. You’d still need to see how the servers cope when several sites are slow or timing out together. The figures leave out your time, paid alerting, extra storage and backups.

1. A script on your laptop ($24 a month with a separate page-speed server)

If you already own the laptop, there’s no hosting bill for the checks it runs. You could run the browser tests on it too and skip the $24 server. Either way, the laptop has to stay awake and connected. If it goes to sleep, a dashboard showing the last result can say “Up” for hours while nothing is being checked. A separate heartbeat service can tell you when the script stops checking in.

Even with the laptop awake and the Wi-Fi working, you’re seeing the site through your home ISP. If your ISP has trouble reaching the network that hosts the site, the script can report an outage while customers on other connections get through fine. If your broadband goes down altogether, the laptop can lose access to both the website and Slack. From your phone, the empty channel looks exactly the same as it does when everything’s fine.

Local caches can make things weirder. A browser-based check can sometimes load a saved copy even when the live site can’t be reached. A plain HTTP script skips your browser’s page cache, but it can still get an old DNS answer. If you’ve just moved the site, the laptop could still be checking the old server while customers are already reaching the new one.

Then you have to give the script a way to send alerts. For Slack, that’s a secret webhook URL. For email, it could be an API key limited to sending mail. Claude can write the code with a placeholder and you can add the real key yourself. Someone still has to store it, replace it when it changes and check that the messages get through. With StatusCake, the checks run externally and can carry on while your laptop and home connection are both offline.

2. A GitHub Action (about $271 a month in our private-repo example)

GitHub’s built-in schedule can run at most once every five minutes. GitHub also says scheduled jobs can run late or get dropped when it’s busy. If you want a fresh job every minute to match Superior’s uptime interval, you’ll need an external scheduler to trigger it.

Say you put all 100 uptime checks in one job per minute and each job finishes within one billed minute. That’s 43,200 billed minutes in 30 days. On a private GitHub Free repo with all 2,000 included minutes available, the extra minutes cost $247.20 on the standard two-core Linux runner. Add the $24 browser server and you’re at $271.20, before the scheduler or any separate jobs. Standard runner minutes can be free on a public repo, but you still have to arrange the scheduling.

You also need to save the last result for each URL. Otherwise one outage can fill Slack with the same message every minute and leave everyone guessing when the site comes back.

3. One cloud server for the checks ($36 a month including page-speed hosting)

We’d start at $12 a month for the server running uptime, domain and SSL checks. That buys a basic DigitalOcean server with one virtual CPU and 2 GiB of memory. The $4–$6 options are cheap enough to try a script on, but we’d want more headroom before relying on one to keep 100 checks a minute on schedule. Add the separate $24 browser server and the estimate comes to $36 a month.

The test we’d run is what happens when several URLs stop responding together. A healthy site might answer in a fraction of a second. A broken one can tie up a check until it times out. Add retries and the next round of checks can start running late, right when you need it most.

You’re also relying on one machine’s view of the internet. If it times out, is checkout down for customers or is the server having trouble reaching it? Retrying gives you another answer from the same place. Someone still has to handle restarts, keep the logs and work out why the alerts went quiet when the person who built it is on holiday.

4. Cloud servers in three regions ($60 a month before confirmation servers)

Three $12 uptime servers plus the $24 browser server come to $60 a month. You can now check from different parts of the world, but you still need to decide what to do when the results disagree.

Say Frankfurt reports a failure and the other two regions are fine. If you wait for a majority, you can miss a real outage for customers in Frankfurt. If you send an alert on every failure, one server with a dodgy connection can wake somebody up. What you want is a second server in Frankfurt to check whether it sees the same thing. That’s where the cost starts to climb.

5. An AI agent that reads every response (about $10,836 a month in this example)

In the other setups, AI can write the code and leave the scripts to run. Here, you pay the model to look at every response. At Claude Haiku 4.5’s rates, one call per check with 2,000 input tokens and 100 output tokens comes to $108 a month for one URL checked every minute. At 100 URLs, that’s $10,800 for the model alone. Add $12 for the uptime server and $24 for the browser server and you’re at $10,836. Ordinary scripts handle domain and SSL in this example.

You could cut that bill by only calling the model when a regular check finds something odd. If you call it every time, you’ve added another service that has to respond before the check can finish. If all you want to know is whether checkout contains the expected text or redirects to the wrong page, you can set those rules directly in StatusCake.

The confirmation catch

There’s a difference between checking from three regions and having another server confirm a failure in the region where it happened. If Frankfurt fails and New York works, that tells you something useful about New York. It still leaves the question of what customers in Frankfurt are seeing.

With StatusCake, you can configure up to three confirmation checks. When an uptime check fails, other servers in the same monitoring region recheck the site before it’s marked down and an alert goes out. The default is two confirmation checks. If one of the confirmation servers can reach the site, StatusCake won’t mark it down on that attempt. This helps cut out false alarms from a single server without requiring the rest of the world to see the same outage.

Here’s what that does to the three-region DIY example.

What you want in each region	Uptime servers across three regions	Monthly hosting including page speed
One server to run the initial check	3	$60
One initial server and one confirmation server	6	$96
One initial server and two confirmation servers	9	$132

That’s one way to build it, using the same $12-per-server budget throughout. At $132 a month, you’ve budgeted for the servers to provide two confirmations in each region. You still have to write the logic that asks for those confirmations, handles a server that doesn’t answer and sends a single alert when it has enough evidence. With StatusCake, you choose how many confirmations you want in the test settings.

The checks that are easy to forget

Domain expiry. Your website can work fine today while the domain is due to expire next week. A DIY check needs to look up the registration data, pick the right expiry date and send a reminder early enough for someone to act. ICANN notes that registry and registrar expiry dates can differ, so grabbing the first date you see can give you the wrong answer. StatusCake includes advance domain expiry alerts.

SSL expiry and errors. An expiry reminder gives you time to fix a missed renewal. You also want to know if a deployment serves a certificate for the wrong hostname or one a browser won’t trust. Both can break HTTPS while the certificate is still within its dates. StatusCake can validate SSL on uptime checks and run dedicated certificate checks with advance expiry alerts.

Page speed. An HTTP response can come back quickly while the page itself takes ages to load. Running a browser every 15 minutes gives you measurements. You still have to save the results, decide when to alert and leave enough detail for someone to see which request slowed the page down. StatusCake gives you load-time and page-size alerts, a history of results and a breakdown of the resources loaded by the page.

What we’d want at three in the morning

Say your homepage is still loading from the CDN cache, but checkout sends customers to an error page that returns 200 OK. A homepage check can stay green, and so can a checkout check that only looks at the status code. With StatusCake, you can check the checkout URL itself, look for text you expect to see and verify where a redirect ends up.

Now suppose checkout comes back before anyone opens the alert. A message that just says “Website down” leaves you trying to recreate an error that’s already gone. In the StatusCake incident view, the person on call can see when the check first failed, where it ran and what status came back. When the response body and headers are available, they can see what the check actually received.

If you’ve built a replacement, run it alongside StatusCake for a test. Break checkout while the homepage still loads, then bring it back before opening the alerts. Give both results to someone who didn’t set up either monitor and ask them what happened.

That’s the comparison we’d make before switching. We’d keep StatusCake because we want the person on call fixing checkout with the incident details in front of them, while the same account keeps watching the domain, the certificate and how long the page takes to load.

Sources and pricing

• Plan prices, server prices and model rates. StatusCake pricing, DigitalOcean Droplet pricing, Claude Haiku 4.5 pricing
• GitHub scheduling and billing. Workflow scheduling, Scheduled workflow troubleshooting, Actions billing, Runner pricing
• Monitoring and incident details. StatusCake confirmation checks, HTTP test settings, Page-speed monitoring, StatusCake changelog
• Caching and domain expiry. MDN on offline browser caching, Cloudflare on DNS caching, Cloudflare on cached pages during an outage, ICANN on registrar and registry expiry