Work / Web · In the lab

Ping Bouncer

Your alerts channel is a nightclub with no door. Ping Bouncer stands at it, filtering and routing alerts from Datadog, Grafana, Sentry and more so only what matters gets through.

The problem

Every monitoring tool your team runs feeds the same alerts channel, and after enough integrations that channel stops being useful. Real incidents get buried under noise, and everyone starts tuning it out.

How it works

Point your monitoring tools at Ping Bouncer instead of straight at your alerts channel. It accepts webhooks and email from Datadog, Grafana, CloudWatch, Alertmanager, Sentry, Vanta, or anything that can send generic JSON. From there, rules decide what happens to each alert: label it, filter it, rate-limit it, group it with related alerts, or route it on.

Where alerts go

Not every alert deserves the same treatment. Critical issues can go straight to incident.io, non-urgent ones to Linear, and pure noise to a searchable archive instead of a channel. Anything else can be routed to a custom HTTPS endpoint.

Shipping rule changes safely

Rules are tested live against real payloads before they publish, and changes roll out gradually, 10% of traffic, then 50%, then 100%, rolling back automatically if error rates climb. A queryable event log covers every request that comes through, filtered or not, so nothing disappears silently.

Under the hood

Sources
Webhooks and email from Datadog, Grafana, CloudWatch, Alertmanager, Sentry, Vanta, or any generic JSON payload.
Rules
Label, filter, rate-limit, group and route alerts. Test each rule live on real payloads before publishing it.
Destinations
Critical alerts to incident.io, non-urgent ones to Linear, noise to a searchable archive, or any custom HTTPS endpoint.
Rollouts
Rule changes ship staged, 10% then 50% then 100%, with automatic rollback if error rates spike.
Logging
A queryable log of every request, including the ones a rule filtered out.
Status
In the lab, working through the idea.

Follow Ping Bouncer