Separate shared health from fleet detail

Reliability surfaces often fail in one of two directions.

They either hide too much from ordinary operators and support teams, or they reveal too much infrastructure detail to everyone who can sign in.

Neither extreme is necessary.

A better pattern is to keep the broad health view coarse and widely readable while making sensitive detail fail closed to the narrower role that actually needs it.

That split matters because health data serves two jobs at once.

One job is shared awareness.

Is the queue moving.

Is the API responding.

Is the worker pool broadly healthy enough that the team can speak calmly about current status.

The second job is deep intervention.

Which worker is lagging.

Which host is missing.

Which region is carrying the anomaly.

Those jobs do not need the same audience or the same payload.

Broad health and sensitive detail are different products #

A public or broadly accessible health summary exists so more people can answer basic operational questions without escalation.

Support can see whether the platform is degraded.

An on-call engineer arriving mid-incident can see whether the damage is local or systemic.

A product lead can understand whether a customer-facing update should be cautious.

That view gets stronger when it is simple.

Healthy, degraded, backlog rising, dependency unstable.

Those signals are already useful.

They do not require per-worker identity, internal network layout, or machine-level status fields.

Sensitive fleet detail is a different product.

It exists for intervention, not shared orientation.

That detail can reveal capacity shape, worker naming, internal topology, or host-specific weakness.

Once it is exposed too broadly, the product has traded a small convenience gain for a larger security and trust problem.

The right design move is not to collapse both audiences into one response.

It is to make the broad response good enough on its own, then attach deeper detail only where the role boundary can support it.

The failure mode is usually over-sharing by convenience #

Many teams do not intentionally decide to leak sensitive detail.

They simply reuse the same response object for every signed-in user because it is faster than designing two views.

The admin card already exists.

The internal endpoint already has the fields.

The frontend already knows how to render them.

So the broad health page quietly inherits more detail than it should.

That shortcut is attractive because it feels harmless during development.

Everyone looking at the page is trusted.

The incident is active.

The team wants visibility.

Later the role boundary widens, the page reaches more people, and the response still carries fields that were only safe under the original assumption.

The stronger pattern is split response design.

One response for shared health orientation.

One response for deeper intervention.

The public-facing shape remains compact and intentionally coarse.

The privileged shape is explicit about why the extra detail exists and who can see it.

Coarse does not mean vague #

A coarse health view should still help real decisions.

It can expose status class, affected service area, backlog direction, last successful check time, and whether the current issue appears localized or widespread.

That is enough for most non-admin users to understand whether they are looking at a product issue, a support issue, or an incident that needs escalation.

The broad surface does not need to reveal the machinery that only the intervention path needs.

That distinction also improves product quality.

When teams know the broad view has to stand on its own, they are forced to design a clearer shared language for health.

Instead of dumping raw internals onto the screen, they define what ordinary readers actually need to know.

That makes the product easier to use and easier to defend.

The boundary should fail closed by default #

Health surfaces drift over time.

A field gets added for debugging.

An internal card becomes useful during a late-night incident.

A second page starts reusing the same serializer.

If the system does not fail closed, sensitive detail tends to spread by inertia.

The safer default is simple.

If the caller does not have the role for intervention detail, the system should return only the coarse health shape.

Not the full shape with a few fields hidden.

Not the full shape with client-side filtering.

A separate, bounded response.

That keeps accidental expansion smaller and makes audits easier because the trust boundary is visible in the contract itself.

At Stack Dispatch, this matters because delivery infrastructure is judged not only by throughput but by whether the product exposes the right evidence to the right role.

Ordinary operators need enough truth to act responsibly.

Administrators need enough detail to intervene precisely.

Those are compatible goals when the product treats shared health and sensitive fleet detail as separate response contracts.

Separate shared health from fleet detail because operational trust depends on proportion as much as visibility.

When the broad surface answers the common question well and the privileged surface keeps the deep answer behind the right boundary, the system becomes easier to operate without becoming easier to map.