Find the next diagnostic check
Start with the symptom, collect the relevant observations and use them to narrow down the cause.
Sources and scopeRead before use
Navigation or project guidance; not a claim of product, standards or environment validation.
On this page
Choose the symptom#
| What you see | Start with | What that check does not prove |
|---|---|---|
| A late or out of order event | Time and event correlation | Clock disagreement alone does not prove network delay |
| A camera is online but the image is frozen | Video service health | Host reachability does not prove fresh decoded frames |
| Duplicate events after a reconnect | Delivery and retry behaviour | A duplicate record does not prove a second physical event |
| A stream cannot be opened | RTSP and SDP inspection | A valid session description does not prove codec support or permission |
| A certificate check fails | TLS and certificate trust | Disabling validation does not fix identity or trust |
| Revoked access appears to remain active | Credential lifecycle | A server update does not prove enforcement at an offline controller |
| Values look plausible but are wrong | Data models and semantics | Valid syntax does not prove units, identity or meaning |
| A command timed out | Uncertain operation results | A missing response does not prove the command had no effect |
Work one example through#
Take a synthetic door alarm with a device timestamp, a receipt timestamp and a UI processing timestamp. First confirm what each field means. Then compare the clocks and follow the record across the adapter and queue.
If receipt was timely but display was late, the downstream path is a sensible next place to inspect. If the clocks disagree, establish clock quality before calling the difference delivery latency. Either way, keep the original record.
This is a reasoning example, not a report of a tested field incident.
Leave a useful handover#
Record the symptom, exact version, observation, next check and what remains uncertain. Use runbooks and observability to make the result usable by someone else.
Do not repeatedly operate equipment to reproduce a symptom. Any live change needs the appropriate site authority and product procedure.