# Setting Up Monitoring Alerts in Slack, Teams & via Webhook

> Setup per channel: Slack, Microsoft Teams, webhook, plus the webhook payload structure (JSON) for your own pipelines. With examples.

Source: https://uptimeify.io/blog/monitoring-alerts-slack-teams-webhook

Monitoring that detects outages but only sends an email to a rarely opened inbox is only half the battle. The real value arises where the alert lands: in the channel your team keeps open all day anyway, or in the pipeline that turns it into a ticket automatically. **Alerts are only useful once they land in the right place**, and that means: in Slack, in Microsoft Teams, or via webhook in your own system. This article shows the setup per channel and the structure of the webhook payload you use to feed alerts into any pipeline of your own.

- **An alert is only as good as the channel it lands in.** Email alone is often seen too late.
- **Slack & Teams** bring the alert to where the team already works, immediately visible, in context.
- **Webhooks** feed the alert into your own pipelines: ticketing system, automation, custom dashboard.
- **The payload is freely built:** a JSON template with placeholders like `{{websiteName}}`, `{{status}}`, `{{errorMessage}}`.
- **Test before the real thing:** a test trigger shows whether delivery and format are right before the first real alert.

## Why the channel decides an alert's value

It's worth pausing on the obvious, because it's surprisingly often underestimated: an alert only has value if someone sees it in time. The monitoring can detect an outage in seconds and confirm it precisely, but if the notification then lands in an inbox that's opened only the next morning, all that speed was for nothing. Detection is one half; delivery to the right place is the other, equally important one.

The default route, an email to an address, has its weakness exactly here. Email is asynchronous and easy to overlook, especially when a lot of it arrives. In a team that works all day in Slack or Teams, email is the channel least likely to be watched in real time. There, the alert competes with newsletters, invoices, and automated notifications, and, in doubt, gets lost.

The solution is to bring the alert to where attention already is. For most teams that's a chat tool; for automations it's a webhook that feeds the alert straight into a system. The right channel choice turns a notification that might be seen into one that's guaranteed to show up in the right place. That's what setting up the channels is about.

Detection and delivery are two halves of the same value. A precisely detected outage is worthless if the alert lands in a rarely opened inbox. The right channel brings it to where attention already is.

## Slack & Teams: the alert in the work chat

For most agencies a chat tool is the most natural place for monitoring alerts, because the team is present there all day anyway. An alert that appears as a message in a channel is seen immediately, can be discussed right in the thread, and sits in the context of the rest of the team's communication. Setup follows the same basic principle in Slack and Microsoft Teams.

The core is an **incoming webhook** on the chat tool's side. In Slack you create an incoming webhook URL for the desired channel, a special address to which messages can be sent that then appear in exactly that channel. In Microsoft Teams it works analogously via an incoming webhook (or a corresponding connector) for the target channel. That URL is the key: whoever has it can post messages to the channel.

In the monitoring you store this URL as a notification channel, at Uptimeify as one of the Slack or Teams type channels. From that moment, the monitoring sends every confirmed outage as a message to that URL, and it appears in the channel. A practical tip: create a dedicated channel for monitoring alerts (say `#alerts` or `#monitoring`), rather than mixing them into a general channel. That keeps the alerts visible and avoids fatigue in a channel where other things also happen. For different clients or urgencies you can set up multiple channels and thus multiple notification channels.

Slack and Teams follow the same principle: create an incoming webhook for the target channel and store its URL in the monitoring as a channel. A dedicated `#alerts` channel keeps alerts visible and free of noise.

## The webhook: alerts into your own pipeline

Slack and Teams cover the case where a human should see the alert. The generic webhook covers the more powerful case where a *system* should react to the alert. A webhook is at its core nothing more than an HTTP request the monitoring sends, on an outage, to a URL you define, and because you control both the URL and the content, you can feed the alert into practically any system.

The use cases are varied. The webhook can create a ticket in your helpdesk, so every outage automatically becomes a trackable case. It can trigger an automation, say in a workflow tool, that kicks off further steps. It can write the alert into your own dashboard or your own database to link it with other data. Or it can drive a chat service that doesn't exist as a ready-made channel. The webhook is the universal adapter connecting the monitoring to the rest of your tools.

At Uptimeify you configure the webhook via the escalation configuration: you set the target URL, the HTTP method (POST, PUT, or PATCH), optional headers, and, the decisive part, the body as a template. Add to that practical fine-tuning: a timeout, a number of retry attempts at a defined interval in case the endpoint doesn't respond immediately, and the expected status codes that mark a successful delivery. That makes the webhook not just a "send something out" but a robust, configurable delivery.

A webhook is an HTTP request to a URL of your choice: the universal adapter to feed alerts into ticketing systems, automations, or custom dashboards. Configurable with method, headers, timeout, retries, and expected status codes.

## The payload structure: building the JSON body yourself

The actual core of a webhook, and the part that interests the technical track, is the body: the payload the monitoring sends to your system. And here lies the real flexibility: you don't dictate a fixed format but build the body as a **template** with placeholders that the monitoring fills with the real values of the outage when it fires.

The available placeholders cover the relevant information of an incident: `{{websiteName}}` (name of the affected site), `{{websiteUrl}}` (its URL), `{{status}}` (current status, say `down` or `up`), `{{startedAt}}` (incident start timestamp), `{{errorMessage}}` (the error message, if available), and `{{incident}}` (the incident object with further details). From these building blocks you assemble exactly the structure your receiving system expects.

A simple body template might look like this:

```json
{
  "text": "Outage detected: {{websiteName}} ({{websiteUrl}})",
  "status": "{{status}}",
  "startedAt": "{{startedAt}}",
  "error": "{{errorMessage}}"
}
```

The big advantage of this approach: you aren't tied to the monitoring's format but adapt the alert to the format of *your* system. If your ticketing system expects certain field names, you name the keys accordingly. If your automation needs a certain structure, you build it exactly so. So when configuring the webhook, you update the target URL, the method, and this body template in one step via a `PATCH` to the escalation configuration:

```bash
curl -X PATCH "https://uptimeify.io/api/escalation-config/1" \
  -H "Authorization: Bearer wsm_<your-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "webhookUrl": "https://your-pipeline.example/alerts",
    "webhookMethod": "POST",
    "webhookHeaders": { "Content-Type": "application/json" },
    "isActive": true
  }'
```

Because you define the payload yourself, the alert turns from a rigid notification into a structured record your own systems can process directly. That's exactly what makes the webhook the basis for real automation rather than mere notification.

The webhook body is a freely built JSON template with placeholders like `{{websiteName}}`, `{{status}}`, `{{startedAt}}`, and `{{errorMessage}}`. That way you adapt the alert to your receiving system's format, instead of being tied to a fixed one.

## Testing and securing delivery

A channel you've never tried is a guess, not a safeguard. That holds for webhooks and chat channels just as much as for an escalation chain. The worst moment to discover that a webhook has a wrong URL or the JSON template has a typo is the first real outage. That's why a test belongs before going live.

Uptimeify offers a test function for the escalation configuration for exactly this: it sends a test webhook (or, optionally, a dedicated PagerDuty or Pushover event) to the configured target and reports the result back, for instance, whether the endpoint was reachable and responded with an expected status code. That way you see immediately whether delivery works and the format is right, before you rely on it when it counts. For a quick check you can even temporarily override the target URL in the test, say to a request inspector, to see the actually sent payload once in raw form.

For ongoing operation, two mechanisms secure delivery. First, **retries**: if the target endpoint doesn't respond immediately, the monitoring attempts delivery again, with a configurable number of attempts and a defined interval between them. A briefly unreachable system thus doesn't immediately lead to a lost alert. Second, the **alert history**: every delivery attempt is logged, with channel type (say `slack`, `email`, `opsgenie`), status (`sent` or `failed`), and timestamp. That makes it fully traceable afterward whether and over which channel an alert arrived, important evidence if there's ever a discussion.

For you to rely on your channels when it counts, test them beforehand. See how Slack, Teams, and webhook delivery can be verified and secured with retries.

## Thinking channels and escalation together

Setting up individual channels reaches its full effect only in combination with escalation. A channel answers the question "where does the alert go?"; escalation answers "what happens if no one responds?". Together they make alerting that's both visible and reliable.

In practice you stagger the channels by urgency across the escalation levels. The first level uses a quiet, integrated channel, Slack or Teams, that reaches the team without ripping them out of everything. If no one responds there within the defined window, the next level kicks in over a more intrusive channel, say SMS or a dedicated service like PagerDuty or Opsgenie. The webhook, in turn, can run in parallel at every level to write the alert into your pipeline independently of the human response, say to always create a ticket, no matter who ultimately responds. Uptimeify supports many channels side by side for this routing, so each level can be tied to the fitting one.

That produces a well-considered system from a few building blocks: Slack for fast visibility, a webhook for automatic processing, an intrusive second level as a safety net. Each building block does exactly one thing well, and together they ensure an outage is not just detected but also seen, processed, and, in doubt, escalated.

Channels answer "where?", escalation answers "what if no one responds?". Stagger quiet channels (Slack) on early levels, intrusive ones (SMS) on late ones, and run a webhook in parallel to process alerts independently of the human response.

## From detected outage to the right response

The heart of this topic is the realization that monitoring is only complete once the detected outage reliably triggers the right response. The best detection in the world fizzles if the alert lands in the wrong channel or arrives in a rigid format your systems can't do anything with. Setting up the channels is therefore not a sideshow but the step that turns monitoring into a working early-warning system.

The three building blocks together cover every case. Slack and Teams bring the alert to where humans see it immediately. The webhook with a freely built payload feeds it to where systems process it automatically. And the test function, together with retries and the alert history, ensures this delivery is not just set up but reliable. All three run on the same calm foundation: confirmation from multiple EU locations before an alert fires at all, so only real outages reach the channels.

In the end it's about closing the gap between "the monitoring noticed it" and "someone or something responded." Set up your channels deliberately: the chat for visibility, the webhook for automation, the test for certainty, and you turn an alert that might arrive into one that's guaranteed to trigger the right response. That's exactly the difference between monitoring that only observes and one that acts.

Close the gap between detected outage and the right response. See how Uptimeify routes confirmed alerts to Slack, Teams, and via webhook into your pipeline, with a freely built payload and a test function.