I recently made some changes to the Music Browser API and during deployment to production I made an interesting discovery. One of the changes was to move some system data from source code to an environment variable so I could modify it without having to do a deploy. I wanted to make sure things were happy so I opened the log stream page for the service in the Azure portal to watch the startup process. It all went fine, except right after the service started I saw a bunch of these errors in the log:
ERROR in __init__: 404 Not Found: The requested URL was not found on the server.
2025-05-04T05:13:00.2685329Z 169.254.136.1 - - [04/May/2025:05:13:00 +0000] "GET /robots933456.txt HTTP/1.1" 404 0 "-" "HealthCheck/1.0"Something about this message was a bit familiar, in the sense that I think I’d seen it before just from looking at the logs of the various apps I have running in Azure. But I never had any unexplained breakage of things and so I never looked into it further.
This time I found it more than a little annoying. I really wanted to see a clean startup for this service, with absolutely no errors. And these days I find that I want to see that for *any* web service of mine or that I maintain. So I took to Google and learned that, just as it says in the message, this is Azure’s app service health check. From some Azure documentation:
You might see the following message in the container logs:
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"You can safely ignore this message.
/robots933456.txtis a dummy URL path that App Service uses to check if the container is capable of serving requests. A 404 response indicates that the path doesn’t exist, and it signals to App Service that the container is healthy and ready to respond to requests.
OK, awesome. Health checks are useful and every cloud provider has them. And I know creating a robust and effective health check can be tricky, but the Azure one leaves something to be desired. It tries to request a dummy robots file, which probably isn’t going to be there. I guess yes, if a service responds with a 404 it is technically alive and able to respond to requests. But is that a sign of good health? I’m dubious. If anything I’d want a health check to check something that has a known expectation, like responding with a 200 because a certain path was requested that should return that status. Or requesting a file that should exist if everything was deployed properly. Seeing a bunch of 404 errors in my log doesn’t suggest ‘healthy’ to me.
So I set about trying to get rid of the errors. I threw an empty robots933456.txt file in my project but that had no effect. It turns out Flask apps will only respond to paths you tell it about. So I had to manually add a definition for a GET request to that file that matched what the health check was looking for. In that function I just return an empty string. Now the log entries show 200s and it’s green lights across the board.