Send Alerts Where Your Team Actually Lives — Slack, Discord, Telegram and Webhooks

Here's a monitoring failure nobody puts in a postmortem: the alert fired perfectly, on time, with all the right details — into an inbox nobody was looking at. The site was down for forty minutes, the email arrived in minute one, and it sat between a GitHub digest and a SaaS invoice until someone's customer tweeted at them.

An unread alert is functionally identical to no alert. If your monitoring only sends email, your real detection time isn't "when the check failed" — it's "when someone next triages their inbox." This post is about closing that gap: routing alerts into the chat tools your team already stares at all day, and doing it with enough structure that they don't just become inbox noise with a different logo.

Why email-only alerting quietly fails

Email is a fine alert channel — as a backup. As the primary channel it has three structural problems:

• It's asynchronous by design. Email's whole contract is "read this whenever." That's exactly the wrong contract for "production is down right now."
• It competes with everything. Your outage notification is fighting for attention against newsletters, receipts and CI noise. Filters help until the day the filter is why nobody saw it.
• It's individual, not shared. An email goes to people; an outage belongs to a team. When an alert lands in five inboxes, it's easy for all five people to assume one of the other four is on it.

Chat channels invert all three: they're glanceable in seconds, they're where attention already is, and everyone can see whether someone has reacted, replied or claimed the incident.

Meet your team where it already lives

The right channel is whichever one your team has open at 2 PM on a Tuesday:

• Slack — the default for most companies. Incoming webhooks make posting trivial, and threads give each incident a natural place for discussion, screenshots and the eventual "resolved, here's what happened."
• Discord — increasingly common for small teams, indie products and open-source projects. Same webhook simplicity, and it's often where a solo founder genuinely lives.
• Telegram — underrated for alerting because its mobile notifications are aggressive in the best way. A Telegram bot posting to a small group is one of the fastest paths from "check failed" to "human saw it," especially off-hours.

The tool matters less than the principle: alerts should interrupt an app your team already checks reflexively, not one they have to remember to open.

Channel design: #alerts is not #incidents

The most common mistake after wiring up chat alerts is dumping everything into one channel. Within a month it's muted. Split it:

• #alerts — the raw feed. Every state change from monitoring lands here: down, degraded, recovered, certificate expiring soon. It's a log you can scroll, not a place anyone is expected to watch continuously. Muted-by-default is fine.
• #incidents — human territory. Only confirmed, actionable problems get posted or escalated here, and a message in this channel means someone needs to do something now. This channel is never muted, and posting noise into it is treated as a bug.

The separation does real work: it keeps the full audit trail without training people to ignore the channel that matters. A useful rule of thumb — if a message in #incidents didn't result in a human taking an action, it belonged in #alerts.

Paged vs notified

Not everyone needs to be interrupted by everything. Decide, per monitor and per severity, who gets paged and who gets notified:

• Paged — actively interrupted: a Telegram ping that buzzes a phone, an SMS, a mention in #incidents. Reserved for confirmed downtime on things customers pay for. This list should be short — usually whoever is on the hook this week, plus one fallback.
• Notified — able to find out without being interrupted: the message in #alerts, the email trail. Everyone else. They'll see it next time they look, which is exactly appropriate for a staging box or a 30-days-to-expiry certificate warning.

Teams that skip this decision default to paging everyone, which is indistinguishable from paging no one — diffuse responsibility means everyone assumes someone else has it.

Dedup and recovery notices — the difference between signal and spam

Two mechanical details decide whether your chat alerts stay useful:

• Alert on state changes, not on state. One message when the monitor goes down. One message when it recovers. Not a message every sixty seconds while it's down — a 40-minute outage should be two messages in the channel, not forty. Anything else buries the incident in its own echo.
• Always send the recovery notice. "Back up after 12m 40s" closes the loop, tells whoever was mid-investigation to stand down, and quietly builds a readable incident history in the channel. An alert system that announces failures but not recoveries leaves every incident looking permanently open.

Deduplication matters across channels too: if the same outage pages Telegram and posts to Slack, both should reference the same incident, so nobody wastes ten minutes discovering that two alarms are one fire.

Webhooks: alerts as data, not just messages

Chat integrations cover most teams. Webhooks cover everything else — a generic HTTP POST with a structured payload lets you pipe alerts into whatever your team runs: an on-call rotation tool, a ticket system, a status page, a script that restarts a flaky service, or that internal dashboard someone built on a Friday.

A useful webhook payload looks something like this:

{
  "event": "monitor.down",
  "monitor": {
    "name": "API — production",
    "url": "https://api.example.com/health",
    "type": "http"
  },
  "check": {
    "status_code": 503,
    "response_time_ms": 4210,
    "location": "eu-west"
  },
  "incident": {
    "id": "inc_8f2a91",
    "started_at": "2022-09-13T02:41:07Z"
  },
  "timestamp": "2022-09-13T02:41:22Z"
}

The details that matter: a stable incident ID (so your pipeline can correlate the eventual monitor.up with the original monitor.down), machine-readable event types, and enough context that the receiver never has to call back to an API just to know what happened. With that shape, a twenty-line script can open and auto-close tickets, or flip a banner on your status page — no vendor-specific glue required.

Wire it up once, stop missing alerts forever

The pattern is simple: raw feed to a log channel, real incidents to a loud channel, page a short list of humans for confirmed downtime, notify everyone else passively, and expose the whole stream as webhooks for anything custom. Every piece exists to serve one goal — shrinking the gap between "the check failed" and "a person is acting on it."

CompleteStatus sends every alert wherever your team lives — email, Slack, Discord, Telegram, and webhooks with structured JSON payloads — with per-monitor routing, deduplicated incidents and automatic recovery notices, alongside uptime, SSL and DNS monitoring in one dashboard. Create a free account, point a webhook at your Slack channel, and the next outage will interrupt your team in the place they'd have seen it anyway — just forty minutes earlier.