A successful health response does not prove that a message has been delivered, a model request succeeded or a payment settled. Use message status, signed webhook events and your organization’s configuration to assess individual operations. A policy-disabled service is not necessarily a platform outage; see availability.
Uptime dashboard
A separate public monitoring dashboard is being prepared forstatus.sendlyy.app. The intended hostname is not a live availability promise: it will be linked publicly after its deployment, DNS, TLS and initial checks are verified.
The dashboard records real checks of web hosting, API/data readiness and documentation, with heartbeat history and operator incident/maintenance updates. Historical percentages cover the recorded observation period; no uptime history is invented before monitoring starts. WhatsApp delivery, AI inference, payments and organization-specific setup are not continuously exercised by these checks.
Public viewing does not require a customer account. Only the monitoring operator can edit incidents and monitor configuration. No provider keys, organization API keys, recipient data, message content or private database details should be exposed by the page.
During a disruption
Save the response’sX-Request-Id and your internal operation ID. Never include your API key, webhook signing secret or OTP in a support report. For an unknown send outcome, retry the identical payload with its original idempotency key; do not create another logical send merely because a status page reports a problem. See errors and retries.
The monitoring service must be hosted independently of the main application’s server/network if its public page must remain accessible during a complete host outage. Monitoring gaps are not evidence that every service was available.