Public API & ingest
OperationalAccepts /api/v1/ requests and inbound webhooks. The entry point for every alert.
Last 90 days
Service transparency
Status model for the services that carry your alerts
When a notification leaves your monitoring tool and reaches a phone or Telegram, eight services have to be healthy. This page names them, shows their state and explains how WardenPoint communicates if any of them degrades.
All systems
OperationalOperational
No active incidents at the moment. Trailing windows shown below.
- Uptime
- 99.99%
- P99
- ~142ms
- Window
- 90d
Service grid
Eight services on the alert path
Each card lists a service that has to stay up for alert delivery, its role in the pipeline, and a trailing 90-day timeline. Amber means a partial degradation we recorded.
Routing & channel resolver
OperationalParses payloads into typed notifications and picks recipient channels per priority.
Last 90 days
Telegram dispatcher
OperationalSends text and voice messages, places Telegram VoIP calls via MadelineProto.
Last 90 days
PSTN voice dispatcher
OperationalOriginates phone calls through the Asterisk platform for critical escalation steps.
Last 90 days
SMS & WhatsApp dispatcher
OperationalSends SMS, WhatsApp and Viber messages through configured upstream providers.
Last 90 days
Email dispatcher
OperationalSends transactional incident emails via the configured SMTP relay.
Last 90 days
Escalation queue
OperationalHolds escalation chains, fires the next step when a timeout expires or cancels on acknowledgement.
Last 90 days
Database & audit log
OperationalPersists notifications, recipients, escalation chains and the structured audit trail.
Last 90 days
Scope
What this page covers — and does not
Some failure modes are inside WardenPoint and we report them here. Other failure modes live with the channel providers or your monitoring source — we say so explicitly.
Our ingest, routing and escalation
If the public API stops accepting alerts, if the dispatcher hangs or if escalation steps do not fire on time, we record it here as an incident.
Our channel adapters
If our Telegram, voice, SMS, WhatsApp or email dispatcher fails to hand a message to the upstream provider, that is in scope.
Third-party provider outages
Telegram, SMS carriers, mail relays and the PSTN have their own outages. We report the impact on alert delivery but cannot fix the upstream issue.
Communication policy
How we communicate during an incident
An alerting platform that goes quiet during an outage is the worst kind of outage. These are the steps we follow.
- 1
Detect
Our own monitors raise an alert internally as soon as ingest latency, escalation lag or dispatcher errors cross a threshold.
- 2
Acknowledge publicly
Within ~15 minutes of confirmation we post the incident here with the affected services and what we know.
- 3
Update on cadence
We post an update at least every 30 minutes during an active incident, even when the only update is 'still investigating'.
- 4
Resolve and follow up
When the service is back, we mark it operational and follow up within five working days with a short post-mortem and the action items.
Stay informed
How to get notified of status changes
Different teams want incident notifications in different places. Pick whichever path matches how your on-call works.
Email digest
Subscribe to status email updates from the account dashboard. You receive incident open, update and resolve notes.
Webhook (recommended)
Register an incident webhook URL in the dashboard. We POST a JSON payload on every state change — wire it into your own routing.
Direct contact
If you suspect impact and we have not posted yet, reach out via the contact form with your alert timeline and request id.
Free plan
Run a delivery test before you depend on it
The fastest way to trust this page is to send your own test alert and watch the timeline. No credit card. No commitment.
- Free forever plan
- Send a test alert today
- Audit log per dispatch