Skip to content
OpsKnight
Install
NAVIGATEOpsKnight
Live status ↗
Install OpsKnight GitHub

PAGING

Reach the responder. Not just their inbox.

Route urgent pages through configured providers and inspect attempts, retries and terminal delivery outcomes.

Install OpsKnightRead the documentation

WHAT IT SOLVES

Intent first. Delivery evidence next.

The notification control plane stores a logical intent and provider-specific attempts. Routing and admission decide eligible work; callbacks add delivery evidence without rewriting the incident lifecycle.

Understand the capability
01Multi-channel routing
02Twilio voice for triggered incidents
03Delivery evidence and retry visibility
OPSKNIGHT / PRODUCT VIEW Northstar Systems · v2.0.0
OpsKnight paging product view
OpsKnight paging product view

HOW IT WORKS

A concrete operational path, not a feature list.

DELIVERY CONTROL PLANESeparate the logical notification from provider admission, attempts, and evidence.
01Incident
02Intent
03Traffic lane
04Provider
05Attempt
06Evidence
CriticalTransactionalPublicBulk

EXPLORE A WORKFLOW

  1. 01Triggered incident
  2. 02Eligible responder
  3. 03Provider admission
  4. 04Attempt & feedback

Time-sensitive responder work retains a stable delivery identity. Provider acceptance is separate from confirmed delivery.

OPERATIONAL DEPTH

Paging, beyond the happy path.

The details below are the parts teams need when evaluating how the capability behaves during real response, failure, and handoff.

01

Critical, transactional and bulk work.

Notification priority and worker lanes keep time-sensitive response work distinguishable from general and bulk processing. Inspect admission, oldest queue age and lane health together when capacity is constrained.

Read the operational guide
02

Route to people and service destinations.

Configure lifecycle events, channels and healthy responder endpoints. Slack and Teams service destinations receive lifecycle messages; linked destinations are not an ordered fallback chain.

Read the operational guide
03

Voice for the triggered incident.

Twilio voice paging supports responder acknowledgement input. Acknowledgement and resolution events do not start additional voice calls. Test the call input against the actual incident state.

Read the operational guide
04

Retry the operation, not the incident.

Transient failures, provider rate limits, deferred work and permanent failures require different actions. Inspect the existing retry schedule, respect provider hints and correct bad credentials or endpoints before retrying.

Read the operational guide
05

Accepted is not the same as delivered.

Trace the notification ID, attempts, provider message ID, callback outcome and next-attempt time. Superseded intents are discarded when a newer incident state makes them stale.

Read the operational guide
06

See the failure where it happened.

Use Notifications Operations and Health Center to connect provider failures, capacity and worker availability. Provider delivery is an operational outcome to verify, not a promise attached to a queued page.

Read the operational guide

KNOW BEFORE PRODUCTION

Validate the boundary, not just the happy path.

Use a test service and representative provider configuration before treating paging as production incident infrastructure.

Triggered incidents with responder acknowledgement input. Acknowledgement and resolution events do not initiate additional calls.

  1. 01Validate every required provider credential and responder endpoint.
  2. 02Test admission, retry or rate-limit handling, and a permanent-failure path.
  3. 03Monitor critical queue age and provider callbacks separately from provider acceptance.
DOCUMENTATIONSetup, authorization, limits, and troubleshooting.
Explore paging documentation

Your incidents should belong to you.

Run OpsKnight on infrastructure you control.

v2.0.0 · AGPL-3.0-only · Self-hosted · 28 inbound integrations

Install OpsKnightStar on GitHub