Check history is the evidence trail for a site. It lets you filter completed runs by target, check type, status, date, error code, failures, slow responses and detected changes.
What a run contains
A run can show its target, check type, status, duration, time to first byte, redirect count, HTTP status, error code and bounded evidence. DNS and TLS runs provide the relevant normalized records or certificate facts.
Use filters to narrow the problem
- Choose a date range when investigating a deployment.
- Filter by target or check type to separate HTTP, DNS and TLS behaviour.
- Use failures, slow responses or changes to find the relevant runs.
- Filter by error code when the same diagnosis appears repeatedly.
Compare before and after
Start with the first failing run, inspect preceding successful runs and then review recovery results. Differences in status, duration, final URL, resolved address or evidence often identify whether the cause is application, network, DNS, TLS or content related.
What history does not provide
History records what WebCheck observed. It does not contain a complete browser session, private application logs or every visitor path. Use it alongside your deployment, proxy, DNS and application logs.