I do not pay for uptime monitoring. I have a tiny file called health.php sitting in the api/ folder of ramrom.io, and it tells me more about the health of the site than a dashboard full of charts ever did. It is about twenty lines of PHP, it costs nothing to run, and it has caught problems before my visitors did.

The idea is simple. A health endpoint is a URL whose only job is to answer one question: is this site actually working right now? Not "is the server up", not "did the homepage return a 200", but "can the site do the thing it exists to do?" For a downloader, that means: can PHP run, can the config file be read, and is there a network route out to the providers? If any of those fail, the site is down in every way that matters, even if the homepage loads beautifully.

Here is roughly what mine does. It starts by setting the content type to JSON. Then it runs a few small checks and collects the results into an array: PHP version, whether the config file exists and is readable, and whether a quick request to a provider domain resolves. Each check is a yes or a no, with a short note. Finally it prints the array as JSON and sets the HTTP status code — 200 if everything passed, 503 if anything failed.

That status code is the whole trick. A 200 means "all good". A 503 means "something is broken". Every free uptime checker on the internet understands that difference, so I pointed one at https://ramrom.io/api/health.php and told it to ping me when the status is not 200. I get an email the minute something goes wrong, and I get it for free. No agent to install, no subscription, no third-party script running on my pages.

There are a few details worth getting right. First, keep the endpoint fast. A health check that takes ten seconds is useless — the checker will time out and report a false alarm. Mine does no real work: it does not resolve a video, it does not call the full provider API, it just confirms the pieces are in place. If I need a deeper check, that is a different endpoint with a different name.

Second, keep it honest. It is tempting to make a health endpoint always return 200 so the monitor stays green. That defeats the purpose. If the config file is missing, I want the 503. A green light I cannot trust is worse than no light at all.

Third, keep secrets out of it. The response should say "config: ok", never the contents of the config. My health endpoint never prints a key, a path, or anything a stranger could use. It is a public URL by design, so I treat it like one.

Fourth, do not let the endpoint itself become a problem. On shared hosting, a checker hitting it every minute is nothing — it is a few kilobytes of PHP with no database and no heavy lifting. But I still made sure it does not write logs on every hit, because a log file that grows by a line a minute is a disk problem waiting to happen.

The best part is what it catches. A provider going down, a config file accidentally overwritten during a deploy, a PHP version change after a hosting update — these are the failures that a plain homepage check misses completely. The homepage is static HTML; it will happily return 200 while the whole download pipeline is broken. The health endpoint is the only URL on the site that actually exercises the moving parts.

If you run a small tool on shared hosting, this is the cheapest monitoring you will ever set up. One small PHP file, one free checker pointed at it, and you will know about a problem before your visitors start emailing you about it. That is the whole point: the site should tell you it is broken, not the other way round.