Do I get a stream of messages during an attack?

No. One message goes out when an attack is confirmed and one when it is over. What happens in between you see live on the attack page in the dashboard; the link is in every message.

Does it work with Microsoft Teams or Mattermost?

The Slack-compatible webhook works with any system that accepts the Slack format, such as Mattermost. The JSON webhook is meant for other systems: a small receiver turns it into whatever your own system expects.

What if my webhook address leaks?

Anyone who knows the address can send messages to it, but without your secret key nobody can produce a valid signature. A receiver that checks the signature rejects those messages. If the secret key itself leaks, create a new one in the dashboard.

DDoS notifications in Slack, Discord or your own system

When an attack is confirmed, the account owner and your NOC contacts receive an e-mail; how you then follow the attack is covered in Following a DDoS attack. But mail is not always where your team is. The discussion during an incident happens in a chat channel, and if you want your monitoring, ticketing or status page to react, a message written for people is no use. That is what the webhooks are for.

Two kinds of webhook

Under Network → DDoS → DDoS notifications you fill in one or both:

Slack-compatible webhook — a formatted message in a channel. Works directly with Slack; for Discord, add /slack to the end of the webhook URL.
Webhook (JSON) — a POST with the attack as structured data, for your own systems.

DDoS notification settings in the Xyphen IT dashboard with a Slack-compatible webhook, a JSON webhook, test buttons and the secret key — Network → DDoS → DDoS notifications: e-mail, the two webhooks, a test message per webhook and the secret key.

After saving, one button sends a test message to each webhook. Do it straight away: a wrongly pasted URL is something you want to find now, not during the first attack.

The chat message names the target, the kind of attack, the peak, how much reached you and what share was held back, when the attack started and how long it has lasted, with a link to the attack page. If mitigation is already running, it also says you do not need to do anything. That one line saves a lot of questions in the channel.

One message at the start, one at the end

A common worry is that an attack floods a channel. It does not: per attack one message goes out once it is confirmed, and one when it is over. Signals that turned out not to be an attack send nothing. The course in between, such as peaks, vectors and measures, you follow live on the attack page.

What the JSON webhook sends

The JSON webhook sends the same kind of message at start and at end. Shortened:

{
  "schema_version": 1,
  "event": "start",
  "attack_id": "01a10627-3e65-7ef0-a505-5e9b37ce4ff3",
  "state": "confirmed",
  "target": "192.0.2.10",
  "prefix": "192.0.2.0/24",
  "attack_type": "single-host",
  "first_seen": "2026-10-04T09:03:17Z",
  "peak": { "bps": 2400000000, "pps": 310000 },
  "delivered": { "bps": 40000000, "pps": 4000 },
  "vectors": [{ "cls": "udp/123", "bps": 2200000000, "pps": 290000 }],
  "mitigation": [{ "kind": "rate-limit", "since": "2026-10-04T09:03:40Z", "until": null }]
}

The most useful field is often delivered: what reached you after mitigation. With it you build your own threshold. An attack of ten gigabits of which 40 Mbit/s comes through need not wake anyone up; if enough comes through to fill your uplink, it should. Other uses we see: automatically opening a ticket with the attack_id in it, an annotation in your traffic graphs, or a notice on your status page.

Check that it comes from us

A webhook address is not a secret you can rely on; it sits in configuration files and sometimes in logs. That is why we sign every JSON message. The X-Xyphen-Signature header contains a timestamp t and a signature v1: the HMAC-SHA256 of t.body with your secret key. Your receiver computes the same signature and rejects messages that do not match or are older than five minutes. The latter stops anyone from replaying an old, valid message.

import hmac, hashlib, time

def verify(header: str, body: bytes, secret: str) -> bool:
    parts = dict(p.split("=", 1) for p in header.split(","))
    expected = hmac.new(secret.encode(), f"{parts['t']}.".encode() + body, hashlib.sha256).hexdigest()
    fresh = abs(time.time() - int(parts["t"])) < 300
    return fresh and hmac.compare_digest(expected, parts["v1"])

The secret key is in the dashboard next to the webhooks. Treat it like a password. If you suspect it has leaked, create a new one; your receiver rejects messages until you have entered the new key there.

Webhooks only go to https addresses on the public internet. The dashboard refuses internal and private addresses, so a webhook can never be used to reach something inside our network.

Webhooks at Xyphen IT

E-mail notifications come with every customer with DDoS protection through IP transit or colocation. The webhooks are an add-on you take on top; without it, the dashboard shows in that spot how to request it. Want to know what else is possible during an attack, or have someone watching alongside you with NOC as a Service? Get in touch.