WebCheck stores bounded evidence so you can understand a result without turning every monitoring run into a copy of the target website. The exact fields depend on the check type and configured assertions.
Common run metadata
Completed runs can include status, start and finish times, duration, time to first byte, response size, HTTP status, redirect count, error classification and the final URL.
Check-specific evidence
HTTP and content checks can store content hashes and configured assertion results. DNS checks store normalized supported records and a record hash. TLS checks store certificate subject, issuer, SANs, validity, expiry, TLS version and cipher details. TCP checks store connection timing and classification.
Boundaries
WebCheck does not store complete response bodies, cookies or authorization headers as check evidence. It does store the configured target URL and can record the final URL in run evidence; query parameters may therefore be retained. Alert payloads can also include the target URL. Do not put passwords, API tokens or other secrets in a monitored URL, including its query string. Content assertions store the configured phrase and its result, so choose a phrase that does not expose private information.
How to use the evidence
Use the evidence to compare a failing run with preceding and recovery runs. It is diagnostic context about the monitored request, not a complete copy of the application state or a replacement for server logs.