The result at a glance

927SCHEDULED CHECKS
926FINALIZED IN THE EXPORT
877SUCCESSFUL CHECKS
49TERMINAL CHECK FAILURES

These totals describe scheduler and collection outcomes. They do not mean that 49 security incidents occurred. A failed check can mean that Guardian could not obtain the evidence required to make a security assessment.

What each monitor completed

MONITORFINALIZEDSUCCESSFULTERMINAL FAILURE
HTTPS availability4544540
DNS perimeter2562551
TLS certificate73730
Email security71710
Trust Controls722448

The export contained one DNS job still outstanding when it was generated. That is why 927 scheduled checks and 926 finalized checks appear together. The snapshot must not be presented as a later, cleaner state.

The most important lesson was semantic

Trust Controls could not collect HTTP-header evidence for 48 scheduled jobs during a period when the site was unavailable. Each job exhausted three attempts, producing 144 failed attempts. Calling those outcomes “48 vulnerabilities” would have been false. The correct result is that evidence could not be collected after retries.

Guardian reporting now separates three questions: did the worker complete the check, was the required evidence available, and did that evidence support a security finding?

Cadence needs historical context

The report covered a nominal 30-day window, but monitoring for this property began on 17 October. It also included observations collected before a cadence change. An average interval across the whole export therefore cannot be read as the current schedule. The export records monitoring start time, current effective cadence, and observed average interval separately so the reader can see that distinction.

For HTTPS availability, 454 checks completed successfully and the observed average scheduling interval was 896 seconds, close to the current 900-second cadence. That is evidence about this monitor in this short window, not a universal service-level guarantee.

What this field note does not prove

  • It covers one owned domain over roughly five days, not a representative customer population.
  • It does not prove that every outage, attack, page, transaction, or private system would be detected.
  • A successful check means the specific public signal was collected; it is not a certificate that the entire business was secure.
  • The figures come from an export generated on 22 October 2026 and intentionally preserve its one outstanding DNS job.

Why publish the uncomfortable part?

A security product should make its uncertainty visible. Publishing the failed collection window is more useful than turning every number green: it shows where the system observed a signal, where it could not, and how the reporting meaning was corrected.