Running is not the same as healthy

A service can exist without doing useful work. Fleet Console keeps process existence, listening ports, host reachability and configured health-check results separate so that one observation cannot silently stand in for another.

Four questions, four kinds of evidence

Question	Evidence to inspect	Remaining uncertainty
Does the process exist?	Current process identity	It may be stuck or serving the wrong result
Is a port listening?	An observed listener associated with the process	The application may reject requests
Is an endpoint reachable?	The specific reachability probe	Another protocol or service can still fail
Did the configured health check pass?	A check that actually ran and its result	The check may cover only part of the user's task

A declared port is an expectation, not an observed listener. A configured check is an instruction, not a completed check. A running service without a check is Running (unverified), not healthy.

Freshness changes the conclusion

Read observation times before accepting a status as current. A previous passing check does not establish health after a process restart, controller disconnection or sampling gap. A recorded event remains useful history, but its presence does not prove the service is still running.

Paused services retain resources and are not checked as if they were actively responding. Do not interpret their silence as a new check failure or as proof they released their ports.

What to do with an attention item

First identify the service and the observation responsible for the finding. Inspect its record, logs and relevant events. Ask whether the check reflects the useful result you care about. Do not restart an unrelated process to clear an indicator, and do not widen control authority by claiming it.

The maintained Fleet Console documentation defines these separate facts. Use logs and events to investigate, then safe controls only if the owner authorizes a specific action.