Request Demo
ZENQIX Documentation
Published

Troubleshooting principles

A safe public troubleshooting order for endpoint state, product reachability, actions, evidence and remote support.

Start with observed state

Troubleshooting should begin with the last known endpoint evidence rather than immediately repeating an action. Confirm device identity, last seen, platform status and capability before deciding whether an operation is eligible to run.

For an action that did not achieve the expected state

  • Separate dispatch from execution and execution from verification.
  • Review provider result, timeout, cancellation and any bounded output.
  • Refresh the relevant endpoint observation after execution.
  • Treat a mismatch or unknown result as unresolved rather than converting it into success.
  • Avoid repeated execution until duplicate/idempotency behavior is understood.

Escalation evidence

  • Device identity and platform.
  • Last-seen time and capability state.
  • Action or support-session identifier where safe to share.
  • Requested state, observed state and verification result.
  • Timestamps and sanitized error category without credentials or secrets.

Use documentation to prepare the pilot.

Add any unresolved deployment or operating question to the evaluation checklist before rollout.