A status endpoint that's coarse in public, detailed in private

A public status indicator should tell visitors whether the service is available. Operators may need component details to diagnose a failure. We separated those audiences so the public response could remain useful without disclosing the internal service inventory.

Define two response shapes

The public response contains a small allowlist, such as an overall status and observation time. The authorized response can include the diagnostic information required by operators. Construct each shape explicitly; filtering a large internal object after the fact is easier to get wrong.

Keep authorization on the server

When a frontend server needs detailed health information, it authenticates server-to-server. It sends only the approved public fields to the browser. A credential used for the internal request belongs in managed server configuration and must not enter client bundles, logs or page data.

Test failure conditions

• An absent, empty or incorrect credential must not enable detailed output.
• An explicit operator permission must be checked independently against the intended access policy.
• Credential comparison should use the framework's appropriate constant-time mechanism, after validating that both values are present.
• Detailed responses must not enter shared public caches.
• A timeout or failed dependency must produce the documented unknown or degraded state rather than a fabricated healthy result.

Verification should compare anonymous, authorized and rejected requests, including warmed caches. It should also inspect what the browser receives, because an internal request can be correct while its result is accidentally serialized into the page.

What this gives the operator

The visitor receives a bounded availability signal. The operator retains a separate diagnostic view with enough context to investigate. Atlas and our observability work apply this distinction when deciding which signals belong to which audience.