Operations
Open Scheduled Monitoring →Choose what to observe
Scheduled Monitoring checks HTTPS availability and certificate observations for a public domain. Choose an IP family and interval appropriate to the problem, then complete verification before creating the monitor. Start with the hostname users actually visit. A monitor for one domain and family is not evidence about every backend, URL path or regional user connection.
Understand how observations become alerts
Checks continue on the server when the browser closes. The current implementation uses two consecutive problem results for an in-app alert and warns when certificate expiry is below 30 days. Inspect timestamps and the latest observation rather than assuming that a quiet screen means nothing happened. Alerts are viewed in Monitoring; there is no email or SMS delivery in this feature.
Account for sampling and retention
A periodic check can miss a short outage between runs. A pair of failures provides evidence at those observation times, not a precise outage start and end. The service permits up to 10 monitors per browser, and schedules expire after 30 days without access. Clearing the monitoring cookie can lose access to schedules. Deleting a monitor removes its stored history and alerts, so retain needed evidence first.
Respond with a diagnostic workflow
For a certificate warning, inspect the live SSL result and plan renewal with the server operator. For an availability failure, compare DNS, HTTP and the selected IP family before changing configuration. Current checks originate from the active test location; the four advertised regional probes remain planned. Use the monitoring history alongside other evidence when assessing user impact, rather than publishing a global uptime percentage from incomplete observations.
Worked example
Illustrative example — not a live test Check 1, 10:00: HTTPS timeout Check 2, 10:15: HTTPS timeout Alert: review in Monitoring These observations do not prove a continuous 15-minute outage.
What to check next
- Create a monitor for the actual hostname and required IP family.
- Review timestamps, recent observations and in-app alerts regularly.
- Investigate with DNS, HTTP and TLS tools before changing the service.
Common questions
Will I get an email when a check fails?
No. The current feature provides in-app alerts, which you must review in Monitoring.
Does the browser need to stay open?
No. Checks run on the server, but the schedule’s access and retention limits still apply.