Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I'm massively enjoying my experience of Envoyer so far. $10 I will happily pay for the foreseeable future.
For myself, the Health Check URL feature (Combined with Slack notifications) is just tremendous. However, specifying a link to my home page isn't exactly maximising it's potential.
I'm keen to pick people's brains about how I could go about providing a Health Check URL to Envoyer, which leads to a Test Page which checks the status of all routes (even those that have Auth Middleware attached).
My first thought was to use a foreach loop combined with the get_headers function to check the status of all routes. Then throw a 404 from the Test Page if any of the routes themselves generate a 404.
I'm not sure that you'd want to do this. From my understanding, the health check is more to determine that the server is is serving up your app correctly, not that your app itself is fully functioning. That should be handled by your test suite
Health checks are basically simulating three users from various continents accessing your server - from New York, London and Singapore.
Your routes have nothing to do with it. You should have written tests to confirm your app works as you'd expect.
As @toniperic said it is the role of test to check all route works. It is not the purpose of healthchecks.
Thanks all.
I'm not asking for Health Checks to replace my Unit Tests however. More to check that the production server is serving up all routes without errors.
If your Unit/Acceptante/Integration Tests are green there are no reason that your application doesn't work.
@RomainLanz - Of course there are! If your production server is subtly different to your local development server, would be an example. Or a vast volume of page requests could be another. I'll be honest in saying, I don't stress test my code. Therefore I am not truly exposing it to a production environment and could honestly never be 100% confident that my application wouldn't fail.
Regardless, my question is not about testing but appreciate your responses.
@olimorris Im not really a server guy but Im sure there is a lot of ways to get noticed somehow when something goes wrong on your server.
Not really the aim of the health check though. If you want to check all of your routes, best to get a monitoring solution up to do that. Something like Nagios or Pingdom.
Or if you want something simple and free (for 50 monitors I think), you can try http://uptimerobot.com/.
Really have to chime in here with a systems administrator perspective.
Writing end to end health checks to test the availability of the underlaying infrastructure the app uses is a no brainer for monitoring systems with real world repercussions in case of failure. Sure if you're writing a dinky little SaaS no one will use, you don't need to, but if you're creating something serious with financial penalties in case of failure, it's basically a mandatory requirement outside the scope of Unit/Acceptance/Integration tests.
Sure you can monitor as much as possible using a tool like Nagios, file system free space, database availability, as well as use orchestration tools like puppet or chef to help deployments, but there can be loads of little gotchas along the way. Sure there's free disk space, but has something weird happened to make it read only? Maybe someone misconfigured the application and it only has read access to the database, not write access? Maybe the DBA forgot to add database credentials? Maybe you've a cluster of 10 nodes and someone forgot to deploy to the 9th node so the versions are out of step and every 10th page request is generating an error?
The easiest way to monitor that is to check the output of a health page/route for an OK to confirm everything is ok and then use the systems monitoring to help identify the route cause of the problem.
To not write health check routes for monitored systems is just lazy.
Please or to participate in this conversation.