First response to a client
Know whether WebWatch recently observed an outage before you reply to a client email or call.
Website downtime alerts
WebWatch keeps the first alert path simple: use account-email coverage, show which monitors are covered, and keep incident evidence nearby when a client site goes down.
Agency overview
Client site status
18
Covered
1
Slow
0
Incidents
Retail client
client-site.example.au
Bookings site
client-site.example.au
Agency site
client-site.example.au
18 monitors covered by email alerts
Confirm one slow response threshold
What it helps with
Each page in this cluster maps back to the same launch promise: public website checks, clear alert coverage, and status evidence for agency-owned client work.
Know whether WebWatch recently observed an outage before you reply to a client email or call.
See whether monitors have active alert coverage instead of assuming every site will notify you.
Webhook controls are being built behind closed gates so public alerting does not outrun egress, signing, and support checks.
Workflow
The launch path stays narrow enough for trust: add the site, know what will notify you, then read the latest observed state.
Add the client website and confirm the monitored target before relying on recurring checks.
Use the default email path first, then treat webhook-style destinations as gated advanced work.
Use latest status, timing, and incident context to decide whether to escalate, wait, or contact the host.
Practical answers
No launch claim is made for SMS, voice, or escalation policies. WebWatch starts with email-first alert coverage.
No. Webhook delivery controls exist behind closed gates, but public webhook creation waits for support, retention, and controlled smoke checks.
No. WebWatch launch copy avoids SLA promises. The alert and incident views are for practical client-site operations.
Create the monitor intent first, then finish account setup and alert coverage inside the dashboard.