One green health view cannot describe the entire service
Azure Resource Health helps explain platform-related conditions affecting a resource. A guest heartbeat observes a collection path inside or associated with the machine. An application probe observes a selected user operation. These signals answer related but different questions.
A VM marked Available at the platform layer can still have a stopped web service or broken guest configuration. A missing heartbeat can also reflect monitoring failure rather than a confirmed stopped VM. This guide builds a layered incident timeline instead of choosing one signal as the universal truth.
Setup: define the monitored service and observation points
Record the VM identity, platform health view, guest collection path and application endpoint. Note each signal's timestamp, sampling interval and responsible owner. Identify planned maintenance and user-initiated actions that may explain a transition.
A useful incident matrix is:
Platform health and related event time:
Guest heartbeat or collection evidence:
Representative application operation:
Recent management and maintenance actions:
Evidence gaps and next owner:
Use the full resource identity rather than a display name shared by another environment. Restrict guest diagnostics and application tests to approved paths. A public homepage check is not an appropriate substitute for a privileged business workflow.
Illustrative incident: platform availability hides a stopped service
In this fictional incident, the Azure VM's platform health shows no known platform problem. A guest application service has stopped after a configuration change, so users cannot complete their normal request. Operators initially wait for a platform incident that does not explain the evidence.
The responder compares the guest service state, recent change record and user-operation probe. It routes the repair to the application or server owner while retaining the platform health observation as context. This is not a claim that platform health signals are unreliable; it shows their scope.
Troubleshooting: identify what each observation can prove
| Observation | Evidence | Appropriate conclusion |
|---|---|---|
| Platform Available but application fails | Guest service and request evidence | Investigate the guest or application path |
| Heartbeat is absent while the app works | Agent, collection and destination checks | Monitoring may be impaired |
| Platform status is Unknown | Available platform context and other signals | Keep uncertainty explicit rather than declaring an outage |
| Platform event and application impact align | Resource event timeline and service probes | Investigate the correlated platform condition |
Do not infer a regional outage from one failed application probe. Likewise, do not close a customer incident solely because the platform status returns to Available. Preserve the evidence at each layer and check whether the original business operation recovered.
Route remediation to the failed layer
Correct the evidenced platform, guest, network or application issue through the appropriate runbook and owner. A guest restart is not the default remedy for every monitoring gap. If a platform event is involved, retain the relevant identifiers and support context without inventing a cause not established by the event.
Review alert severity using both signal scope and observed impact. Separate a monitoring-blindness ticket from a confirmed service outage while allowing escalation when the team cannot establish service state. A clear unknown state is more useful than an unjustified green dashboard.
Verification, alerting and SOP
Retest the original application operation, confirm the intended guest monitoring and review the platform status after correction. Observe the relevant recovery window rather than treating one successful sample as proof of sustained availability. Keep planned and unplanned transitions distinguishable in the record.
An internal SLO can describe a specific user-facing operation and its measurement source; platform availability is not automatically that SLO or a contractual SLA. The SOP should record signal meanings, resource identity, timestamps, ownership, correlation rules, uncertainty handling and the acceptance evidence required to close an incident.
See Clouvenix managed infrastructure for a reviewed implementation and operational handover.
Technical reference
Microsoft Resource Health scope and status FAQ, Microsoft Heartbeat table definition. Reviewed 19 October 2026; use documentation for the installed product and release.