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.

Start free Report an incident

All systems

Operational

All systems operational

Live state aggregated from per-component probes. Detail and 90-day timelines below.

Uptime 90d
99.98%
Components
6
Window
90d

Components

Status of each service on the alert path

Every parent has its own 90-day uptime band. Expand a row to inspect the leaf-level providers behind it.

Public API & ingest

Operational
99.99%90d

Last 90 days

Dashboard

Operational
100.00%90d

Last 90 days

Notification dispatch

Operational
99.99%90d

Last 90 days

Asterisk telephony

Operational
99.99%90d

Last 90 days

Database

Operational
99.93%90d

Last 90 days

Redis & queue

Operational
100.00%90d

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. 1

    Detect

    Our own monitors raise an alert internally as soon as ingest latency, escalation lag or dispatcher errors cross a threshold.

  2. 2

    Acknowledge publicly

    Within ~15 minutes of confirmation we post the incident here with the affected services and what we know.

  3. 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. 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.

Start free Contact support
  • Free plan
  • Send a test alert today
  • Audit log per dispatch