Resolve A Failed Endpoint Check

Use this walkthrough when an endpoint Sentinel status or endpoint self-healing history shows a failed check and you need to decide what to do next.

Outcome

By the end of this walkthrough, you will know how to inspect the failure, decide whether automated self-healing is already handling it, and confirm the endpoint is healthy or properly escalated.

Starting Context

• You are signed in.
• You know the endpoint hostname or endpoint id.
• The endpoint has a visible Sentinel status such as Failed, Timeout, Invalid output, Policy denied, Runner error, or Stale.
• You have access to Self-Healing if you need to review endpoint self-healing history or escalations.

Step 1: Open The Endpoint

Open Endpoints, find the endpoint, and select the row.

Start with the endpoint header and identity panel. Confirm:

• hostname and Computer ID
• OS, architecture, and agent version
• Last Seen
• that you are in the expected organization

If the endpoint has not been seen recently, handle freshness first with Respond to stale or offline endpoints.

Step 2: Read The Sentinel Panel

Review the endpoint Sentinel panel before opening a session.

Focus on:

• status
• latest summary
• Last run
• Duration
• Version
• Policy
• active session or agent thread links, when present
• pending escalation count

On mobile, the panel stacks the same evidence vertically. Confirm the status and summary first, then continue down to run timing, policy, session/thread links, escalation count, and knowledge counts.

Decision points:

• Failed: continue into endpoint self-healing history.
• Timeout: treat it as a real failed check unless later history shows a successful newer run.
• Invalid output: the check result could not be parsed into the expected bounded status format.
• Policy denied: the check or attempted action hit a guardrail boundary.
• Runner error: the endpoint runner could not complete the check.
• Stale: compare Last run with endpoint Last Seen before deciding whether this is a check problem or a connectivity problem.

Step 3: Open Endpoint Self-Healing Detail

From the Sentinel panel, use Self-healing to open the endpoint-specific self-healing page. Use History when you want the page focused on Sentinel history.

On the Sentinel tab, inspect:

• active Sentinel version
• latest execution status
• Sentinel version table
• Sentinel execution table

Look for the newest execution first. Older failed executions should not override a newer successful run.

Step 4: Check Sessions, Knowledge, And Escalations

Move through the endpoint self-healing tabs in this order:

1. Sessions: check whether a self-healing session already started, whether it is active, awaiting escalation, or terminal, and whether there is an agent thread link.
2. Knowledge: check accepted endpoint knowledge and pending proposals that may explain a false positive or special handling.
3. Escalations: check endpoint-scoped escalation rows and use Review for a pending decision.

Decision points:

• Active session exists: open the session or thread instead of starting duplicate manual work.
• Terminal session says fixed: return to the Sentinel tab and confirm a newer passed execution when available.
• False positive knowledge exists: confirm the knowledge applies to this endpoint before accepting the failed status as non-actionable.
• Pending escalation exists: review it before taking separate action.

Step 5: Review Escalations When Pharaoh Needs A Human Decision

If there is a pending escalation, open Review.

Inspect:

• category
• requested action
• endpoint id
• thread id
• created and expiry times
• policy snapshot
• existing grants, when any are recorded

Approve only when the requested continuation is acceptable for the endpoint, policy, and incident. Reject with a short reason when the request should not continue.

Step 6: Confirm Resolution

Return to the endpoint detail page or endpoint self-healing page.

A failed endpoint check is resolved when one of these is true:

• a newer Sentinel execution shows Passed
• a self-healing session has a terminal fixed outcome and the current endpoint state matches expectations
• the failure is documented as a false positive through accepted endpoint knowledge or a reviewed proposal
• the issue is escalated and waiting on an operator decision
• the endpoint is stale or offline and the next action is connectivity, power, or enrollment follow-up

Related Pages

• Self-healing and Sentinel
• Review self-healing escalations
• Endpoints and live view
• Respond to stale or offline endpoints
• Session workspace