User Guide

A comprehensive, step-by-step guide to every feature of WardenPoint. If you have a question — the answer is here.

How it works — 4 simple steps

🚀 Getting Started

📊 Dashboard

The dashboard is your main workspace. Here's what each section does:

👥 Recipients

Recipients are the people who receive your notifications. Each recipient must have a name and at least one contact method. The more contact methods you add, the more channels the system can use for delivery and escalation.

Adding recipients

Click 'Add Recipient' in the Recipients section. Fill in the name (required), and at least one of: Telegram username (e.g., @johndoe), phone number (international format, e.g., +380501234567), or email address. You can add all three — this gives the system the most flexibility for channel selection and escalation.

Contact types and what they unlock

Each contact type enables specific notification channels:

Recipient groups

Groups let you organize recipients (e.g., 'Backend team', 'Night shift', 'Management'). When you send a notification to a group, every member of that group receives it. You can also set notification rules at the group level — for example, all members of the 'Critical Alerts' group get voice calls by default.

CSV Import

To add many recipients at once, use CSV import. Go to Recipients → Import. Your CSV must have a header row with columns: name, phone, email, telegram_username. Only the 'name' column is required — others are optional. Example:

📡 Notification Channels

WardenPoint supports 9 notification channels across 7 providers. Each channel has different strengths: text channels are great for informational alerts, voice channels grab immediate attention for critical situations. Here's a detailed breakdown:

🧭 Alert Routing

Routing rules let you automatically direct incoming alerts from monitoring sources to the right recipient group based on alert content — severity, lifecycle status, or any label attached to the alert.

Two match dimensions

Each rule can filter on two built-in dimensions and any number of label conditions. Leaving a dimension empty means match any value.

Label conditions

Match any key/value label the source attaches to the alert — for example team=backend, service=payments, or host=~prod-.*. Four operators are available:

Multiple conditions on a rule are AND'd — every condition must pass for the rule to match.

Per-rule group & accumulation

Each matching rule sends the alert to a specific group and optionally overrides the accumulation window — how long WardenPoint waits to batch similar alerts before dispatching.

Source-aware options

The severities, statuses, and label keys shown in the rule editor are pulled from the integration source you're configuring. A Prometheus alert has different severity values than a Zabbix trigger — WardenPoint shows you the right options for each.

🔔 Priorities

Every notification has a priority level that determines how aggressively it is delivered and escalated. Choose the right priority for each situation:

⚡ Escalation

Escalation is the core feature that makes WardenPoint different from a simple notification sender. When a notification is sent, the system doesn't just fire-and-forget — it tracks whether the recipient acknowledged it, and takes action if they didn't.

What is escalation?

After sending a notification, the system waits for an acknowledgment (ACK) from the recipient. ACK can happen by: clicking an acknowledgment link in a Telegram message, clicking a link in an email, or simply answering a voice call. If no ACK is received within the configured timeout (e.g., 2–5 minutes), the system moves to the next escalation step: sends via a different channel, retries the same channel, or notifies a manager.

Escalation policies

You can create reusable escalation policies in Dashboard → Escalation Policies. A policy is a set of ordered rules: 'first send Telegram text, wait 3 min, then call via PBX, wait 2 min, then notify the manager'. Policies can be assigned to individual recipients or groups.

Available escalation actions

Acknowledgment (ACK)

ACK is how the system knows the recipient got the message. For Telegram text — clicking the acknowledgment link in the message. For Telegram voice/call — the message being delivered. For email — clicking the acknowledgment link. For voice calls — answering the call. Once ACK is received, the escalation chain stops immediately — no further steps are executed.

⚙️ Notification Settings

Notification settings let you fine-tune how each recipient (or group) receives alerts. You can configure these per priority level:

📤 Sending Notifications

There are two ways to send notifications: manually through the dashboard, or programmatically via the REST API.

Sending from the dashboard

Go to Dashboard → Notifications → Send Notification. Select a recipient (or group), type your message (up to 4,096 characters), choose a priority level, and optionally attach an audio file. Click Send. The notification will be processed immediately — you'll see the status update in real time on the Notifications page.

Sending via API

Use the REST API to send notifications from your monitoring tools, scripts, CI/CD pipelines, or any other system. All API endpoints are under /api/v1/ and require an API key for authentication. Here are the available methods:

🔌 API Integration

The WardenPoint REST API lets you integrate notifications into any system. All endpoints are versioned under /api/v1/ and return JSON responses.

Authentication

Every API request must include your API key in the X-API-Key header. You can create API keys in Dashboard → Settings → API Keys. Each key is scoped to your company — it can only access your company's recipients and notifications.

Official SDKs & CLI

Prefer not to call the REST API by hand? Two officially maintained clients wrap every endpoint below — install one, add your API key and you are sending alerts.

API Endpoints

Request body reference (POST /send)

Code Examples

🪝 Outbound webhooks

WardenPoint POSTs to your own systems when notification lifecycle events happen — acknowledgments, escalations, delivery failures. Subscribe your endpoints to the events you care about and react automatically: close tickets, update incidents, kick runbooks.

Available events

Subscribe to one or more events. WardenPoint sends a separate POST for each.

Common request envelope

Every event starts with the same envelope: event name, company UUID, and timestamp. Event-specific fields are merged in on top (see per-event schemas below).

Payload schemas per event

Exact contract for each of the 8 events. Fields prefixed `// optional` may be absent depending on channel.

Signature verification

Every request is signed with HMAC-SHA256 in the X-WardenPoint-Signature header. Always verify the signature before processing the payload — this guarantees the request came from WardenPoint and not from someone who happens to know your URL.

Request headers

Retries & dead-letter

If your endpoint returns non-2xx or times out, WardenPoint retries automatically:

• 5 attempts with 1s / 5s / 30s / 5min / 1h backoff.
• After the final failed attempt the delivery is marked "dead-letter" — visible in the dashboard.
• Hit "Replay" in the deliveries log to re-send a request after fixing the issue on your side.

🛡️ Observability Monitoring

WardenPoint can tell you when a monitored source goes dark — two ways, choose per integration.

🔍 Active mode — WardenPoint pulls your endpoint

Use this when your health endpoint is publicly reachable. WardenPoint sends an HTTP GET to the URL you set, once per minute. If the endpoint replies with a non-2xx status code, or the request times out past the failure threshold, we page your owner group. Once the endpoint responds normally, the alert resolves automatically.

💓 Heartbeat mode — your source pushes a signal

Use this when the monitoring source is inside a private network or behind a VPN and cannot be reached from outside — for example, an internal Prometheus/Alertmanager stack. Instead of us pulling, your source pings WardenPoint's ingest URL on a schedule. If no ping arrives within the configured grace window, we page your owner group.

Prometheus Alertmanager Watchdog example

The canonical setup: an always-firing Prometheus rule drives a regular Alertmanager webhook to WardenPoint. If Prometheus or Alertmanager stops firing, the pings stop, and WardenPoint pages you.

Step 1 — always-firing rule in Prometheus

Step 2 — Alertmanager route and receiver

Notification map

The Map tab on each integration renders your full delivery topology as an auto-generated graph — routing rules, recipient groups, escalation steps, on-call schedules with a live badge showing who is currently on duty, and every fallback path down to the owner-email safety net. The graph is built from your live configuration on every load, so it can never drift from what actually executes. Branches that have received zero events in the last 7 days are shown dashed, making dead or unused paths instantly visible. The built-in simulator lets you dry-run your live rules at any point in time — pick a moment, and the map highlights the exact delivery path along with who is on duty at that instant, without writing a single event to production.

Editing from the map

Routing rules, group membership, escalation steps, and on-call schedule overrides (substituting the person on duty) are editable directly on the map — click any node to open the editor in a right-hand panel. Save goes through the same endpoints as the settings pages; the map re-renders from the database immediately after. Per-recipient channel preferences are not editable from the map — open the recipient's page instead. Shared escalation policies open their own page rather than offering inline editing. What you see on the map is exactly what executes.

📋 Alert templates

Save pre-built alert presets with placeholders once, then fire them from your code with one POST per slug. Variables come from the request body; the rest (recipient, priority, escalation policy) comes from the template.

When it helps

• The same alert message lives in 3-5 places in your codebase — centralise the wording.
• DevOps/runbook references a 'db_down' playbook — the slug becomes a public contract.
• You want to change alert wording without a re-deploy — edit the template body, version auto-bumps.

Fire a template

Pass in the body; backend substitutes them, applies the default priority/recipient, and ships through the same pipeline as /send.

Pinning to a version

Every save creates a new version. Existing callers keep working — add "version": N to the body to pin to a specific historical version.

Override defaults per-call

Pass an "override" object with priority, recipient_uuid and group_uuid keys in the body to swap any default for that single call.

Placeholder syntax

Mustache-lite — substitution only, no logic, no loops:

• {{ var }} — HTML-escaped (default; safe for any channel).
• {{{ var }}} — raw value, no escape. Your responsibility.
• No conditionals, no loops, no expressions — this is not a full templating engine.

🔑 Credentials & Setup

Most channels require external service credentials. Go to Dashboard → Settings → Credentials to configure them. Only email works out of the box — all other channels need setup.

💳 Plans & Billing

WardenPoint offers tiered plans. The Free plan includes Telegram and email; paid plans unlock PSTN voice calls, SMS, WhatsApp and Viber along with higher recipient/voice/SMS quotas and advanced features. The plan cards below are pulled from the live billing config.

Payment methods: credit/debit card via MonoPay or PayPal. Annual plans get a 20% discount. You can change your plan at any time — upgrade takes effect immediately, downgrade at the end of the billing period.

❓ FAQ