Well, sort of. The original downtime was caused by the reverse proxy dying for no apparent reason. This state could be detected by healthchecks. However the quick solution after the second time the container went away while on holiday was to use ‚restart: unless-stopped‘ and I could see a case where the container was down 90% of the time but just-so-happend to be freshly restarted while the healthchecks were looking.
That’s why I decided to use the docker API’s /events endpoint to get notified about all changes. Using dockers healthcheck features you can even monitor the availability of the http server with this solution as well. I did not find a project that went the same route.
The downside to this approach of course is, that if docker goes down you won’t get notified, also if you just use curl inside the container for healthchecks, you won’t notice external network problems. So something that is hosted on the outside like healthchecks.io is a great addition.
That’s why I decided to use the docker API’s /events endpoint to get notified about all changes. Using dockers healthcheck features you can even monitor the availability of the http server with this solution as well. I did not find a project that went the same route.
The downside to this approach of course is, that if docker goes down you won’t get notified, also if you just use curl inside the container for healthchecks, you won’t notice external network problems. So something that is hosted on the outside like healthchecks.io is a great addition.