HTTP/2 Probe — Is the Newer Protocol Actually Being Used
This connects to a host and reports whether HTTP/2 is negotiated, along with the settings the server advertises and how it handles streams. Protocol negotiation happens during the TLS handshake, which means the outcome is decided before any HTTP is exchanged and is invisible in ordinary request logs.
Why run it
Because enabling HTTP/2 and serving HTTP/2 are different achievements. A configuration directive can be present while negotiation quietly fails — an old TLS termination point, a proxy that only speaks HTTP/1.1 upstream, a cipher configuration that the protocol requires and the server no longer offers. Clients fall back silently, so everything works and you simply do not get the benefit you configured and possibly reported as delivered.
Why automate it
Protocol support regresses during infrastructure changes more often than during application ones. A load balancer replaced, a TLS termination point moved, a base image updated — any of these can drop HTTP/2 while everything continues to serve correctly over HTTP/1.1. Since there is no error and no user-visible symptom beyond slightly worse performance, a scheduled check is realistically the only thing that will notice. It belongs with the change-detection checks rather than the alerting ones.
What it gives you
Verification that a performance feature you configured is actually in effect, and detection when an infrastructure change silently removes it. Nothing else in a normal monitoring stack reports this.