Channels
Send alerts to Slack, email, webhooks, PagerDuty and Jira, test them, and see every delivery
A channel is somewhere alerts go. Manage them in Account → Alerts → Channels.
Owners and admins can add and delete channels, because channels hold credentials and decide where your data is sent. Everyone can send a test and read the delivery log.
Adding a channel
- Go to Account → Alerts → Channels and click Add channel.
- Choose where alerts should go, and give the channel a Name.
- Fill in the fields for that type (below) and click Add channel.
- Click Send test. A channel shows Not verified until a test gets through, then Healthy.
Credentials (webhook URLs, keys, tokens) are stored encrypted and never shown again. A channel shows only a short hint, such as …Xa9.
Some channel types can include tag values (such as customer IDs) in notifications. This is off unless you tick Include tag values when adding the channel.
Slack
Create an incoming webhook for the Slack channel you want, then paste its URL into Slack incoming webhook URL.
Each event posts a new message with the severity, status, the main metric and a button to open the incident.
Send to everyone with a role (owners, admins, members), to other addresses, or both. Anyone who unsubscribed from incident alerts is skipped.
Webhook
Enter a Destination URL. It must use HTTPS on port 443 or 8443 and resolve to a public address. Redirects aren’t followed.
After you save, ApiTraffic shows the channel’s signing secret once. Copy it: you’ll need it to check that deliveries really come from ApiTraffic. See Webhook payloads for the body and how to verify the signature.
To replace the secret, open the channel and click Rotate signing secret. The old secret keeps signing for 24 hours, so you can update your receiver without missing anything.
You can add as many webhook channels as your plan allows, and send one route step to several of them. Each is delivered, retried and logged on its own.
PagerDuty
In PagerDuty, add an Events API v2 integration to a service and copy its Integration key. In ApiTraffic, choose the Region (US or EU) and paste the key.
| ApiTraffic event | PagerDuty action |
|---|---|
| Incident opened, reopened, escalated or flapping | Trigger |
| Acknowledged | Acknowledge |
| Resolved | Resolve |
Every event for one incident goes to the same PagerDuty incident. Info incidents, comments and reminders are never sent to PagerDuty.
Jira
ApiTraffic opens one issue per incident and adds later events as comments.
- Jira Cloud: the Site URL (
https://your-site.atlassian.net), the Atlassian account email, and an API token for that account. - Jira Data Center / Server: the site URL and a personal access token. The site must be reachable from the internet.
Also set the Project key (for example OPS) and, optionally, the Issue type (default Task) and a status to move the issue to on resolve (for example Done).
Every issue gets the label apitraffic-inc-, so a retry never opens a second issue. To change the site, the deployment or the account email, enter the token again: a stored token is never sent to a new site.
Channel health
| Status | Meaning |
|---|---|
| Healthy | The last delivery went through. |
| Not verified | Added or changed, and no test or delivery has got through yet. |
| Failing | 3 or more deliveries in a row have failed. Deliveries keep retrying. After 5 in a row, the channel pauses between attempts. |
| Disabled | The destination said it’s gone (for example a removed Slack webhook, an invalid PagerDuty key, or a revoked Jira token). Nothing is sent until an admin fixes it. |
Owners and admins get an email when a channel starts failing, is disabled, or recovers.
Retries
A delivery that fails for a temporary reason (a timeout, a 5xx, a 429) is retried after 30 seconds, 2 minutes, 10 minutes, 30 minutes, 2 hours, 6 hours, 12 hours, then once a day, with some random spread. A Retry-After header is honoured, up to 6 hours. After 3 days ApiTraffic gives up and records it on the incident’s timeline.
A delivery the destination rejects outright (most 4xx responses) isn’t retried.
To protect a channel from floods, once it has sent 60 notifications in an hour, further updates to existing incidents aren’t sent to it (they still show on the incident). New incidents and anything critical are always sent.
Delivery log
Open a channel to see every delivery attempt, newest first: when, which incident, the attempt number, the result (for example server error · HTTP 503 · 412 ms), the start of the destination’s response, and when the next retry is due.
Admins can click Send again on a delivery that failed or wasn’t sent.
Deleting a channel
Deleting a channel destroys its credentials. Its delivery log is kept. Routes stop sending to it.
You can’t delete the only channel of a step of the default route. Point the default route somewhere else first.