Killing 100 Paid Vendor Seats With a Slack-Based On-Call Paging System

The request sounded simple: support, engineering, and customer success all needed to be able to raise an incident and reach whoever was on call. Then the math came back. Giving everyone that access through our existing setup meant buying 100 more seats. That's a lot of money for a button most of those people would press a few times a year.

The problem

We already ran monitoring and alerting on Datadog, and its Incident Response product handled paging for the core on-call engineers. That part worked well. The trouble was who it left out.

In Datadog's billing model, a user needs a seat to respond to pages: being on a schedule, sitting in an escalation policy, or having notification preferences set up to receive pages. Declaring an incident from Slack through the Datadog app also counts as a seat action ("Only Slack actions taken through the Datadog app trigger a seat requirement"). And Slack is exactly where people raise the flag.

Support and customer success are often the first to notice something is wrong. A customer writes in, a few tickets look alike, a demo breaks. Those people need to declare an incident and reach on-call within seconds, without first asking someone else to do it for them. Covering them, plus the engineers outside the core rotation, came to 100 additional seats.

The insight

Incident response best practice is that anyone should be able to raise the red flag. Better safe than sorry: a false alarm costs a few minutes, and a real incident nobody declared costs a lot more. A per-seat gate on declaring works against that. If raising the flag means "go find someone with a license," people hesitate, and hesitation is the expensive part of an incident.

When we wrote down what those 100 people actually needed, it was three verbs:

1. Raise a page and notify the right on-call person.
2. Acknowledge it, so everyone knows a human has it.
3. Escalate it if nobody acknowledges in time.

None of that needed a full product seat per person. Everyone already lived in Slack. Datadog already knew when things broke. We already ran on AWS. The pieces were all there and paid for.

The approach

We built a small paging layer on top of those three tools. Datadog stayed the backbone: monitors kept firing exactly as before, and a webhook integration sent alerts to an endpoint on AWS (API Gateway in front of a Lambda function). The handler looked up who was on call for the affected team, posted a page to the team's Slack channel, and messaged the on-call engineer directly.

The Datadog side is just a webhook with a custom payload, so the handler gets everything it needs to route the page:

{
  "title": "$EVENT_TITLE",
  "priority": "$PRIORITY",
  "team": "$TAGS[team]",
  "link": "$LINK"
}

Humans could raise a page too, with a slash command from any channel. No seat, no special access, just a Slack account. Every page arrived with two buttons:

{
  "type": "actions",
  "elements": [
    { "type": "button", "text": { "type": "plain_text", "text": "Acknowledge" }, "action_id": "page_ack", "style": "primary" },
    { "type": "button", "text": { "type": "plain_text", "text": "Escalate" }, "action_id": "page_escalate", "style": "danger" }
  ]
}

Clicking Acknowledge updated the message for everyone in the channel. Clicking Escalate, or leaving the page unacknowledged past a timeout, moved it to the next person in the escalation chain. The whole thing stayed small enough for one engineer to understand end to end.

The result

We never bought the 100 seats. At Datadog's public list price (as of October 2026), an On-Call seat starts at $20 per seat per month billed annually, so 100 seats would have cost at least $24,000 a year. With the full Incident Response bundle at $40 per seat, it's closer to $48,000.

The money was the headline, but accessibility was the bigger win. Before, raising an incident meant knowing who held a seat. After, anyone in Slack could raise a page in seconds, and the response happened in the tool everyone already had open. More people could pull the cord, and nobody had to think twice about whether they were allowed to.

When to question the pricing model

Per-seat pricing makes sense when every seat gets daily use. It fits badly when you're paying per human for something most humans touch a few times a year. If the workflow they actually need is a handful of verbs on tools you already pay for, a thin internal layer is often the better deal. That goes double for startups, where $24,000 a year is real budget.

The tradeoff is ownership. A pager is something that must work on the worst day, so it needs its own tests, monitoring, and a fallback path. We kept the core rotation on Datadog's product and used the Slack layer to widen who could raise and see pages. That split got us most of the value for a small amount of code.

Questioning a vendor's pricing model and building the lightweight piece that actually fits is exactly the kind of Observability & Monitoring work I can help with at Cloud with Gus.