The lack of a good upstream health check capable of millisecond timing in core Nginx is largely why I use HAProxy in stacks where, in theory, Nginx could replace both HAProxy and the web server behind it (which is often Nginx).
Is it the granularity of the health check that you're wondering about? I've got a deployment where nginx delegates the health check / load balance component to haproxy.
Keep in mind that the "heavier duty" the health check, the less frequently it can be run at scale.
edit: The best clue is probably the phrase "available as part of our commercial subscription only" appearing all over the upstream module documentation.[0]
As I remember a year or two ago they were convinced, that it is ok to send real user's request to a dead backend from time to time to check if it's alive, arguing that dedicated health check wasn't going to make a difference.
The problem with that is the user's request may have generated a legitimate error, or it may not be a good test of all the functionally.
If you write your software with a dedicated healthcheck url, it's much more robust because you can test all critical functionality with that helthcheck (just make sure you block access to it from the outside otherwise someone has a really easy way to DDOS you!).
