Validated monitoring targets
SiteAlert validates destinations before checking them and blocks internal or private network addresses. Monitor URLs cannot contain embedded credentials.
This overview explains the safeguards built into SiteAlert and how monitoring, alerts and shared status information are handled.
SiteAlert validates destinations before checking them and blocks internal or private network addresses. Monitor URLs cannot contain embedded credentials.
One failed monitoring round is recorded first. A second consecutive failed round is required before a downtime incident opens, while planned maintenance suppresses expected uptime and performance alerts.
Monitoring, SSL checks, alerts, webhooks and realtime updates use named queues so different workloads can be processed separately.
Webhook deliveries include an HMAC-SHA256 signature, timestamp, event name, delivery ID and idempotency key. Delivery targets are validated again before each request.
Incident and alert records help prevent duplicate sends. Retryable webhook failures can make four attempts with increasing delays, while terminal results remain visible in delivery history.
Public status pages are opt-in and show selected monitoring, incident and public maintenance information. Account contacts, private maintenance and webhook settings stay private.
SiteAlert reports the delivery stage it can verify rather than treating every queued alert as delivered.
Send a concise description, affected URL or feature, reproduction steps and potential impact to support@usesitealert.com. Do not include credentials, tokens, customer data or destructive proof.