Klaxon
Scheduled Sep 8, 2026On-call that pages people, not your budget.
Replaces
- PagerDuty · PagerDuty, Inc. — $41 per seat per month (Business (billed annually)), about $196,800/yr at 400 seats
- Atlassian Opsgenie · Atlassian Corporation — $19.95 per seat per month (Standard (billed annually)), about $95,760/yr at 400 seats
Rented, per year
$196,800
PagerDuty list price at 400 seats.
Owned, per year
$7,680
AWS infrastructure only. Azure is $8,460.
Build
9 weeks
2 engineers. To parity on the ten core features above, including import of PagerDuty or Opsgenie schedules, escalation policies, services and integration keys, with existing webhook URLs kept working behind a compatibility shim.
Difficulty
4/5
Substantial. Compliance or realtime depth involved.
Reference organisation: 300 responders, ~40,000 alerts/month, ~450 incidents/month, two regions for the notifier, prod + non-prod. 3-year Compute Savings Plan on Fargate, 3-year reservation on Container Apps and PostgreSQL Flexible Server. Excludes carrier charges for SMS and voice, which are passed through at cost and run roughly $180/month at this alert volume. Excludes vendor support plans and LLM gateway token spend. Figures are infrastructure only and exclude the build.
What it is
Klaxon is on-call infrastructure: schedules and rotations, multi-step escalation, alert deduplication and grouping, incident command with roles and timelines, and delivery over SMS, voice, push and chat. It is aimed at engineering organisations with 50 to 500 people carrying a pager, where per-responder pricing has made it expensive to add the people who should be reachable. Klaxon treats being reachable as free and charges nothing per notification.
Why this one stops making sense
- PagerDuty Business is $41 per user per month on annual billing. At 300 responders that is $147,600 a year to make people reachable by telephone.
- Opsgenie stopped being an alternative: Atlassian ended sales on 4 June 2025 and shuts the product off on 5 April 2027. Anyone standing on it is migrating whether they planned to or not.
- Per-seat pricing means teams quietly share a login or leave the on-call rota thin, which is the exact failure mode paging exists to prevent.
- Your incident timeline is the primary evidence in every post-incident review and most regulatory conversations. It should not live behind an API you rent.
- The vendor is in the alerting path for your outages. A dependency that fails during your worst hour deserves the same scrutiny as any other single point of failure.
What ships
- Schedules with rotations, layers, overrides and per-person time-zone handling
- Escalation policies with timed steps, round-robin and fallback to a team channel
- Alert ingestion from Prometheus Alertmanager, CloudWatch, Azure Monitor, Datadog, Grafana and generic webhooks
- Deduplication and grouping keys so a hundred node alerts page once
- Delivery over SMS, voice call, mobile push, email, Slack and Microsoft Teams
- Incident command: declare, assign incident commander and scribe, run a timeline
- Status page generation driven by incident state, on a separate origin and separate failure domain
- Maintenance windows and alert suppression with automatic expiry
- Post-incident review packs assembled from the timeline, alerts and chat transcript
- On-call analytics: page volume per person, out-of-hours load and interrupt distribution
Data model
Stack
- frontend
- Next.js 15 App Router + Tailwind + TanStack Query, plus a deliberately minimal responder view that renders under 40 KB
- backend
- NestJS on Node 22 — REST ingest endpoints, a schedule evaluator and a notification dispatcher as separate processes
- database
- PostgreSQL 16 with Row Level Security per team; schedules stored as rules, not materialised shifts
- cache
- Redis 7 for dedup fingerprints, rate limits and current on-call lookup
- queue
- BullMQ for escalation timers and notification retries, with per-incident ordering
- auth
- OIDC against the customer IdP, with a break-glass local admin path that survives IdP failure
- search
- PostgreSQL tsvector across incidents, alerts and timeline entries
- ai
- Optional alert-storm summarisation and draft post-incident narrative through an LLM gateway
Parity, honestly
What we match, and what we do not.
The rows marked No are the important ones. If one of them is the reason you bought PagerDuty, keep buying it — and we will tell you that on the first call rather than the fifth month.
| Capability | PagerDuty | Ours | Note |
|---|---|---|---|
| Schedules, rotations, layers and overrides | Yes | Yes | — |
| Multi-step escalation policies | Yes | Yes | — |
| SMS, voice, push and chat delivery | Yes | Yes | Through your own Twilio, Amazon SNS/Pinpoint or Azure Communication Services account, at carrier cost. |
| Alert deduplication and grouping | Yes | Yes | — |
| Incident command roles and live timeline | Yes | Yes | — |
| Unlimited stakeholder and read-only subscribers | Partial | Yes | Stakeholders cost nothing, so the whole business can watch an incident without a licence. |
| Mobile app with reliable push and page acknowledgement | Yes | Partial | Klaxon's PWA handles push on Android and iOS 16.4+, but a critical-alert-bypass native iOS app that rings through Do Not Disturb requires an Apple entitlement and a store listing. That is a separate 5-week engagement. |
| Vendor-operated global telephony with carrier redundancy | Yes | No | PagerDuty runs multi-carrier voice and SMS routing across 100+ countries with negotiated deliverability. Klaxon uses one telephony provider you choose. If you page people in 40 countries, PagerDuty's carrier estate is worth paying for. |
| 700+ pre-built integrations with monitoring and ticketing vendors | Yes | No | We build the six or eight you actually alert from. Everything else arrives as a generic webhook you map yourself. |
| Runs outside your own infrastructure so it survives your outage | Yes | Partial | Klaxon's notifier runs active/active in two regions, but if the failure is your cloud account or your IdP, a fully independent vendor is genuinely safer. Some customers keep a minimal PagerDuty seat count purely as a break-glass path. |
| AIOps noise reduction and event intelligence | Yes | Partial | Klaxon groups by fingerprint and time window and can summarise a storm through your LLM gateway. It does not ship a trained cross-customer correlation model. |
| Per-notification and per-seat billing | Yes | No | Klaxon has no per-seat or per-page charge. You pay your carrier for the SMS and nothing else. |
| Migration from PagerDuty or Opsgenie | None | Yes | Schedules, escalation policies, services, integration keys and two years of incident history are imported; existing integration URLs are kept alive behind a shim. |
Reference architecture
Built twice, on purpose.
Every application in Techtons ships with a production architecture for AWS and one for Azure, using the same diagram grammar so you can read them side by side. Your cloud, your account, your bill.
Amazon Web Services
- Compute
- ECS Fargate services (api, evaluator, notifier) behind an ALB, with the notifier deployed to two regions
- Data
- Aurora PostgreSQL in the primary region, plus a DynamoDB global table holding notification dedupe and delivery receipts
- Storage and edge
- S3 for post-incident artefacts, CloudFront for the status page on its own distribution
- Identity
- Cognito federated to the customer IdP, with a local break-glass user pool
- Observability
- OpenTelemetry to CloudWatch and X-Ray, plus an external synthetic that pages a human if Klaxon stops paging
- Infrastructure as code
- Terraform, one module per environment, remote state in S3 with a DynamoDB lock
Services
The decision worth arguing about
The non-obvious decision is running two consistency models inside one product on purpose. Everything transactional — schedules, policies, incident records — lives in single-region Aurora, because on-call configuration is edited rarely and reads fine from one place. But the notifier cannot be single-region: the most likely reason Klaxon needs to page someone is that the region it lives in is having a bad day. So the notifier runs active/active in two regions against a DynamoDB global table that holds only the dedupe key and the delivery receipt, which are the two facts that must survive a region loss. The trade is that DynamoDB global tables are last-writer-wins across regions, so under a genuine partition a responder can receive the same page twice. We took duplicate pages over missed pages, and the notification body carries the incident sequence number so a human can tell the two apart in half a second.
Microsoft Azure
- Compute
- Azure Container Apps (api, evaluator, notifier) in two paired regions, with Front Door routing on health
- Data
- Azure Database for PostgreSQL Flexible Server in the primary region, Cosmos DB multi-region for dedupe and delivery receipts
- Storage and edge
- Blob Storage for post-incident artefacts, a separate Front Door profile for the status page
- Identity
- Microsoft Entra ID, with a local break-glass account outside Entra so an Entra outage does not lock out incident command
- Observability
- Azure Monitor with Application Insights, plus an external synthetic outside Azure
- Infrastructure as code
- Bicep in an azd-compatible layout
Services
The decision worth arguing about
On Azure the escalation timer is the decision worth arguing about. The obvious build uses Durable Functions timers — one orchestration per incident, each step a durable wait — and it is genuinely elegant: exactly-once semantics, replay safety, no timer wheel to write. The problem is the history table. A busy month of alert storms leaves hundreds of thousands of orchestration histories in Table Storage, and purging them is a separate scheduled job that, if it lags, quietly slows every new orchestration start until pages arrive late. Klaxon instead keeps escalation state as rows in Postgres with a next_fire_at column and a Container Apps job that polls every second with SELECT FOR UPDATE SKIP LOCKED. It is less fashionable and it costs a persistent replica that never scales to zero, roughly $35 a month. In exchange the entire escalation state is one table an on-call engineer can query at 03:00 with psql.
Sources
Every price on this page, with the page we read it from and the date we read it.
| Product | Plan | List price | Checked | Source |
|---|---|---|---|---|
| PagerDuty | Business (billed annually) | $41 / seat/month | 2026-09-05 | www.pagerduty.com/pricing/ Monthly billing is $49 per user. Enterprise is quoted by sales. |
| Atlassian Opsgenie | Standard (billed annually) | $19.95 / seat/month | 2026-09-05 | www.atlassian.com/software/opsgenie/pricing Opsgenie reached end of sale on 4 June 2025 and end of support on 5 April 2027, after which the product is shut off and un-migrated data is deleted. This price is a renewal rate for existing customers, not something you can buy today. |
Should you still be paying for PagerDuty?
Two weeks, fixed price. We audit what you actually use, map it against Klaxon, cost the replacement on your own AWS or Azure account, and give you a delivery plan. If the honest answer is to keep the licence, that is what the report will say.