Service health

The Monitoring Operator begins with the service catalogue. Each service has a named owner, a criticality and a current state. Assets attached to that service identify the equipment behind it. Availability checks record when a probe ran, whether it succeeded, its latency and probe location. Server samples add CPU, memory and free disk observations for a particular asset. These are separate observations: a busy server can still answer a check, and a failed check does not by itself identify the cause.

Suppose the billing service fails a check from one probe location. The operator checks whether another location reported the same result, then compares recent resource samples for its assets. A low free disk reading gives the responder a useful starting point. The operator opens an incident with the affected service and asset, selects a priority and assigns a responder. The incident becomes the working record for investigation; the original check and sample remain evidence of what was observed.

• Service context. Keep the service name, owner, criticality and state current so an observation reaches the right team.
• Check history. Review the check time, result, latency and probe location before treating a single failure as a wider interruption.
• Asset samples. Compare sample times and resource readings for the asset linked to the service.

Choose the services to monitor first and identify their owners. Agree which assets belong to each service, how probe locations are named and which observations warrant an incident. Set a clear convention for sample cadence and the person who checks failed observations. A service marked for maintenance should be interpreted alongside its maintenance window; the maintenance record carries the site, opening and closing times and timezone. Keep that context available to responders before they decide whether customers are affected.

Take one service and its linked asset. Record a successful check, a failed check and two samples with different resource readings. Ask the Monitoring Operator to identify the changed observation, open an incident and select the correct asset. Ask the Service Owner to find the incident from the service context and verify that the recorded observations still show their original times. Then repeat with a failure at a second probe location. The team should distinguish a repeated failure from two duplicate incident entries.

A receipt from an external source has its own provider, event identifier, receipt time and disposition. Review a rejected receipt separately from a failed availability check. If an external source is connected during implementation, agree how its event identifier maps to a service and how operators handle repeated events.

• Failed Availability Checks — Find unsuccessful observations by time, location and service.
• Server Sample History — Compare CPU, memory and free disk readings for an asset.
• Rejected Integration Receipts — Inspect events that did not enter the working record.

Continue to incident response when an observation requires investigation. Use service recovery to check the result after action is taken.