Ping Bouncer Sign in

Not every ping
gets in.

Ping Bouncer sits between every alert source and your team. See everything that sends alerts on one map, set the routing rules in one place, and only the pings that matter get through.

Get started See how it works

For SREs, DevOps and Security engineers who are tired of #alerts-prod-2.

The line
STAFF
incident.io Pages only.
0
Linear Real, not urgent.
0
Suppress Recorded. Nobody notified.
0

Where Ping Bouncer sits

Every alert source and where it goes, on one map.

Every tool you own ships a Slack integration. None of them ship judgment. So each one is wired straight to your team, with its own rules in its own settings page. Put Ping Bouncer in the middle and all that wiring becomes one map you can read, change and trace.

  • Datadog
  • CloudWatch
  • Alertmanager
  • Sentry
  • GuardDuty
  • Vanta
  • Status emails

Routing rules? Limited controls in each provider. Nobody remembers them all.

Ping Bouncer

  • workflowprod-infra
  • workflowsecurity-findings
  • workflowvendor-status
  • incident.io
  • #alerts
  • #alerts-prod
  • #alerts-prod-2
  • #alerts-real
  • Shared inbox
  • Linear
  • #vendor-status
  • Suppress

Four channels, all muted

Every tool posts straight to Slack, so the page that mattered at 3am sits between a staging warning and the same flapping monitor for the seventeenth time.

Only what matters gets through

Filters, grouping and rate limits run before anyone is notified, so a flapping monitor becomes one alert instead of seventeen, and a staging warning doesn't have to reach anyone.

Rules in every tool

Each tool decides who to tell in its own settings, so nobody can see the whole picture, and alerts keep going to the inboxes of people who left.

Every source on one map

A tool shows up by name the first time it sends, wired to the workflows and destinations it feeds. It's the first screen you see when you sign in.

Where did this come from?

An alert lands in #alerts-prod-2 and nobody can say which monitor sent it, who set it up, or who else got it.

Every alert, traced

Open any alert to see what sent it, which workflow took it, and where it was delivered, failed or skipped, and why.

Every vendor switch is a migration

Changing your pager or chat tool means re-pointing every monitor, scanner and status page by hand, one integration at a time.

Change tools in one place

Your sources point at Ping Bouncer, not at your pager or your chat. Switching vendors is a route change here, and your monitors never notice.

Keep your pager, your tracker and your chat. Ping Bouncer isn't one more place to look for alerts. It decides which alerts reach them.

  • Incident manager
  • On-call scheduler
  • Observability platform
  • SIEM
  • ✓ The routing layer in front of them

How it works

One endpoint. Your rules. The right place.

  1. 1

    Point every source at one endpoint

    Each workspace gets one webhook URL and one email address. Your monitors, scanners, status pages and uptime checks, even the one that can only send email, all send to the same place.

    POST https://in.pingbouncer.com/v1/ep_7q…/••••••
    MAIL your-team+statuspage@alerts.pingbouncer.com
  2. 2

    Write the house rules

    Workflows shape every alert in order: label it, rewrite it, filter it, rate limit it, group the repeats. Then routes decide where it goes. Test your rules on real payloads before anything goes live.

    LabelCustomizeFilterRate limitGroupRoute
  3. 3

    Send each ping where it belongs

    Pages go where people get woken up. Real work becomes a ticket someone owns. Noise is suppressed: recorded where you can search it, but nobody's notified. Any destination, or your own HTTPS endpoint.

    incident.ioLinearPagerDutyJiraSlackYour endpoint

House rules

Workflows that fit how your team actually works.

Every team's noise is different. Pick one and see how Max handles its night.

workflow prod-infra Metrics · APM · uptime
  1. filter drop when env is staging
  2. label team = {{payload.tags.service}}
  3. group by {{alert.title}} for 30m
  4. rate limit 3 per 10m per {{labels.team}}
severity = critical & status = firing→incident.io
status = resolved→Suppress
everything else→Linear · team from label

A typical night (illustrative)

Received1,204
After filters388
After grouping61
Linear tickets57
Pages4

1,200 pings never touched a phone.

Strong opinions, loosely held

Our defaults are pretty strict. Yours can be anything.

Pages go to incident.io

If it needs a human right now, it should open an incident instead of posting to a channel and hoping somebody sees it.

Everything else goes to Linear

Real but not urgent means a ticket with an owner and a team, not a Slack message nobody gets to.

Noise gets suppressed

Resolved, staging, FYI and duplicates are suppressed. Nobody gets notified, and you can still search them in the events log.

Slack? Sure, if you insist.

It's a perfectly good destination. It just shouldn't be the only place alerts end up. Route what belongs there.

Don't like our taste? Every route is yours to rewrite. ✎

Built by people who read raw payloads

The details you'd want at 3am.

Proof it got there

Every destination keeps its own activity: what was delivered, what failed, when it last worked, and the exact request each delivery sent.

Rules tested on real payloads

The workflow editor runs your rules over recent real events as you edit. Click a field to turn it into a filter, label or route, and see per-step counts before you save.

Drafts and staged releases

Changes are drafts until you publish. Releases roll out 10% → 50% → 100%, the error rate is watched, and a bad release rolls itself back.

An events log you can actually query

Every request, including the ones Max turned away. Drag across the histogram to zoom, and get suggestions as you type.

⌕ schema:uptime-monitor -outcome:filtered "disk full"

Your own endpoint

Send any route to an HTTPS endpoint you own. We POST the alert as JSON, so your Lambda, your queue or your internal tool takes it from there.

POST /hooks/ping-bouncer HTTP/1.1
Host: ops.acme.internal
Content-Type: application/json

{
  "id": "ev_7q4m…",
  "severity": "critical",
  "title": "checkout-api 5xx > 20% (prod)",
  "labels": { "team": "payments" }
}

Add now, set up later

Route to a destination before anyone has its credentials. Send a single-use setup link to whoever holds the keys, and they fill in only the fields you ask for.

No late pages, ever

If a delivery can't go out, it's recorded as skipped, with the reason. It never gets replayed hours later, because a late page does more harm than none.

Isolated from other customers

Your alerts get their own isolated intake and processing, built from your published rules. Another customer's alert storm, or a bad rule they wrote, doesn't slow your pages.

Integrations

Lets in pings from anywhere. Sends them anywhere.

Sources: anything that sends a webhook or email

  • Any JSON webhook
  • Any email
  • Datadog
  • CloudWatch
  • Amazon SNS
  • GuardDuty
  • Security Hub
  • Cloud Monitoring
  • Security Command Center
  • Pub/Sub
  • Azure Monitor
  • Cloudflare
  • Grafana
  • Alertmanager
  • New Relic
  • Honeycomb
  • Splunk
  • Sentry
  • PagerDuty
  • GitHub
  • Snyk
  • Wiz
  • Panther
  • Vanta
  • Oneleet

Destinations

  • incident.io
  • Linear
  • PagerDuty
  • Jira
  • Slack
  • Your HTTPS endpoint
  • Suppress

Pricing

One plan for teams. Enterprise when you need it.

Built for engineering teams who own the pager, not procurement. Start the trial, keep what works, cancel if it doesn't.

Most teams start here

Team

$299/month

14-day free trial. No card to start.

  • Unlimited users, no per-seat fees 1
  • Isolated processing for your alerts. No noisy neighbors.
  • Queryable events log, kept for 30 days
  • Up to 5M events per month, plenty for one team's alert traffic
  • Every workflow and integration included, nothing gated
Start your trial

Enterprise

Contact us

For multiple teams under one org, or a security review to close. Tell us what you need and we'll work it out together.

  • Everything in Team
  • Talk to us about SSO/SAML, audit export, longer retention or more volume
  • Need a DPA or a security questionnaire answered? Ask.
Talk to us

1. Workspaces start with a 20-member limit. Need more? Ask us and we'll raise it. ↩

Meet Max

Head of Door. Employee of the month, every month.

Max has sat through every kind of alert storm there is. Now he works yours. He's polite, he's consistent, and he has never once said “it's probably fine.”

Height
6′5″, plus the attitude
Pings checked
All of them
Pings let through
Only the real ones
Catchphrase
“Not tonight.”
Likes
Dedupe, quiet on-call weeks, clipboards
Dislikes
@channel, flapping monitors, “FYI” at 3am

Questions

FAQ

Is this another incident management tool?

No, and you don't have to rip yours out. Ping Bouncer decides which alerts reach your incident tool, your tracker and your channels. It doesn't run incidents, schedules or status pages. Point your sources at Ping Bouncer instead of straight at the pager or the channel, keep routing to whatever you already use, and move one source at a time.

We're switching pagers. Does this help?

Yes. Everything that sends to your old pager has to be re-pointed anyway, so point it at Ping Bouncer and route pages to the new one. You re-point each source once, and the next time you change tools it's a route change in one place.

What if my tool isn't in the list?

If it can send a JSON webhook or an email, it can send to Ping Bouncer. Payloads Ping Bouncer doesn't recognize show up as shapes you can name, and they become custom event types with their own labels and routes. Webhook bodies can be up to 64 KB. Anything bigger gets a 413, isn't stored, and shows up in the events log as dropped.

Can I send alerts to my own systems?

Yes. Route anything to an HTTPS endpoint you own. We POST the alert as JSON and record whether it was delivered. What happens downstream is yours: a Lambda, a queue, an internal tool, a bot in a chat app we've never heard of.

What happens if a destination is down or not set up yet?

The delivery is recorded as skipped, with the reason, and you can see it in the events log. It's never replayed later, because a page that arrives hours late does more harm than good.

Will other customers' alerts slow mine down?

No. When a big provider has a bad day, everyone's monitors go off at the same time, which is exactly when a shared line would hurt. So your alerts get their own isolated intake and processing. Someone else's flood, or a broken rule they wrote, isn't supposed to slow your pages down. We don't promise specific timings (see the Terms), but that's what it's built for.

What can Ping Bouncer reach in my systems?

Very little, by design. Your tools push alerts to us. We never connect back into your infrastructure, run agents, or hold credentials to your cloud accounts. The only credentials we keep are the ones you give us for destinations, like a Slack bot token or a Linear API key. They're encrypted with a key unique to your workspace and used only to deliver your alerts, so give each one the narrowest scope the tool allows. Everything you send lands in your events log for your retention window, including alerts a rule drops, so if something should never leave your systems, strip it at the source.

Are you SOC 2 certified?

Not yet, and we'd rather say so than call it "in progress." Email hello@pingbouncer.com and we'll answer your security questionnaire, or a standard one like SIG Lite, and send our subprocessor list. Our infrastructure providers, Cloudflare and Clerk each have their own SOC 2 Type II report. Those cover them, not us. If a SOC 2 report is a hard requirement for your team, tell us: requests like that decide when we get one.

Where's the wall of customer logos?

We don't have one, and we're not racing to build one. A grid of logos is herd behavior dressed up as due diligence: proof other people decided before you had to. Point a noisy source at Ping Bouncer and judge it on what it does with your alerts, not on whose logo we talked into a usage-rights email.

How do I start?

Create a workspace at app.pingbouncer.com, point one noisy source at the webhook URL it gives you, and watch what arrives before you write a single rule. Nothing is routed anywhere until you publish.

Every ping should earn your attention.

Point one noisy source at Ping Bouncer tonight. Max will take it from there.

Get started How it works

Sign in and deploy a workflow in about a minute.

Privacy Policy

Last updated October 3, 2026

The short version

Ping Bouncer is a routing layer: it watches for alerts from the tools you point at it, decides where each one should go based on rules you write, and sends it on. We don't read your alerts for our own purposes, we don't sell or share data with advertisers, and we don't use anything that passes through Ping Bouncer to train models. Alert content lives in your events log for 30 days so you can see what happened, then it's deleted. The rest of this page spells out the details.

Who we are

Ping Bouncer is operated by Svelte Services LLC ("Ping Bouncer", "we", "us"). This policy covers pingbouncer.com and the Ping Bouncer app at app.pingbouncer.com. Questions about this policy or your data go to privacy@pingbouncer.com.

What we collect

Three categories, each handled differently:

  • Account data. When you sign up, our authentication provider, Clerk, collects your email address and whatever sign-in method you choose (password, Google, etc.). We store your workspace name, the routing rules you write, and the destinations you connect. We don't ask for more than that to run the service.
  • Alert data. The content of the pings you route through Ping Bouncer: the payload a source sends, which rule matched it, and where it was delivered. This is the data your own tools generate about your own systems — we're a pass-through, not the source.
  • Usage and infrastructure data. Our host, Cloudflare, logs standard request metadata (IP address, timestamps, request paths) for security and abuse prevention, the way any web infrastructure provider does. Our marketing site uses Cloudflare Web Analytics, which is cookieless and doesn't collect personal data or track you across sites.

How alert data is handled

Alert data is processed to do one thing: match it against your rules and deliver it to the destinations you've configured (Slack, Linear, incident.io, a webhook you own, or whatever else you've connected). That delivery is between your source and your destination — we move it, we don't repurpose it.

We keep a record of each alert in your events log — what arrived, which rule matched, and whether delivery succeeded — so you can audit what happened. Those records are kept for 30 days by default and then deleted on a rolling basis. One part of our storage expires on its own fixed schedule rather than on our command, so some event data can take up to three months to be fully gone. Past your retention window it's hidden from everyone, including us.

We don't copy alert content out of that log for analytics, product improvement, or any other purpose. Unless you turn it off under Settings → Product analysis, we keep the structure and outcome of events (which fields a payload had, which rule matched, whether delivery worked) to improve the product, but never what an alert said.

Nobody at Ping Bouncer reads your alert content as a matter of course. The only exception is if you explicitly ask us to look at specific events to help debug a problem, and even then we only look at what you point us to.

Who we share data with

We use a short list of subprocessors to run the service, and nobody else:

  • Cloudflare — hosting, network security, and (for the marketing site only) cookieless analytics.
  • Clerk — authentication, so we never handle your password directly, and subscription billing. Card details are entered through Clerk's billing and never reach us. Clerk's own sub-processors are listed in its legal documents.
  • Your own destinations — the tools you explicitly connect (Slack, Linear, incident.io, a webhook, etc.) only receive the alerts your rules route to them. You control that list and can disconnect a destination at any time.

We do not sell personal data or alert data, and we do not share it with data brokers, advertisers, or anyone outside this list.

Cookies

The app sets one session cookie, from Clerk, to keep you signed in. The marketing site sets no cookies — Cloudflare Web Analytics works without them. We don't use advertising or cross-site tracking cookies anywhere.

Data retention and deletion

Alert and events-log data: 30 days by default on a rolling basis, then deleted automatically, with the last copies aging out within three months as described above. Account and configuration data (your workspace, rules, connected destinations): kept while your account is active.

When you delete a workspace, we stop accepting its alerts immediately, erase every credential and secret it held, and delete its event data. Anything we can't delete directly ages out within three months. We keep a record of the workspace's configuration (without credentials) and a log of the changes made to it, for security and audit, and billing records where the law requires them.

You can request deletion of those records, or an export of your account data, at any time by emailing privacy@pingbouncer.com.

Security

All traffic to and from Ping Bouncer is encrypted in transit (TLS). Credentials and secrets you give us, like endpoint secrets and destination tokens, are encrypted at rest with keys unique to your workspace. Access to stored data is limited to what's needed to run the service. No system is unbreachable, and we'll tell you if something changes that.

Your rights

Depending on where you live, you may have rights to access, correct, export, or delete your personal data, or to object to or restrict how we process it. We honor these requests regardless of jurisdiction — email privacy@pingbouncer.com and we'll take care of it.

International data transfers

Our infrastructure providers (Cloudflare and Clerk) operate globally, which can mean your data is processed in a country other than the one you're in. We don't currently offer a choice of region for where your data is stored. We rely on those providers' own safeguards for cross-border transfers and choose providers that take this seriously.

Children's privacy

Ping Bouncer is a business tool and isn't directed at children. We don't knowingly collect data from anyone under 16.

Changes to this policy

If we change this policy in a way that matters, we'll update the date at the top and, for material changes, email account holders before they take effect.

Contact

Svelte Services LLC. For anything privacy-related: privacy@pingbouncer.com.

Terms of Service

Last updated October 8, 2026

The short version

Use Ping Bouncer to route your own alerts, don't abuse the service or send it things it's not for, and understand that we're a routing layer, not an incident platform or a guarantee that every ping reaches you. The rest of this page is the formal version of that.

1. Agreement

These terms are between you (or the organization you represent) and Svelte Services LLC, doing business as Ping Bouncer ("we", "us"). By creating a workspace or using app.pingbouncer.com, you agree to them. If you're signing up on behalf of a company, you're confirming you have authority to bind it.

2. What the service is

Ping Bouncer receives alerts from sources you connect (webhooks, email, or other integrations), matches them against rules you write, and routes them to destinations you configure. We don't run incidents, on-call schedules, or status pages, and we don't guarantee the behavior of any third-party source or destination you connect — only the routing decision in between.

3. Your account

You're responsible for keeping your login credentials secure and for everything that happens under your account. Tell us at privacy@pingbouncer.com if you suspect unauthorized access. You're responsible for the accuracy of the rules you write — Ping Bouncer routes exactly what you've told it to.

4. Acceptable use

Don't use Ping Bouncer to:

  • Send unlawful content, or alerts whose purpose is to harass, defraud, or deceive anyone;
  • Attempt to overwhelm, probe, or disrupt the service beyond normal use;
  • Reverse engineer or resell the service without our written permission;
  • Route categories of data you don't have the right to process (for example, health, financial, or children's data subject to specific regulatory regimes) unless you've confirmed with us that it's appropriate.

We can suspend or terminate accounts that violate this section, with notice where practical.

5. Your data

You own the alert content and configuration you put into Ping Bouncer. We process it only to provide the service, as described in our Privacy Policy, which is part of these terms. You're responsible for having the right to send us whatever data your sources generate.

6. Third-party destinations

Ping Bouncer delivers alerts to destinations you configure — Slack, Linear, incident.io, a webhook you own, or others. We're not responsible for those services' availability, security, or handling of data once it's delivered. Your relationship with those providers is your own.

7. Fees and payment

Paid plans are billed in advance on the cycle shown at signup, through our payment processor. Fees are non-refundable except where required by law. We'll give you reasonable notice before any price change takes effect for your account.

8. Term and termination

You can cancel at any time from your workspace settings; cancellation takes effect at the end of the current billing period. We can suspend or terminate the service for violations of these terms, non-payment, or if required by law, and will give notice where practical. Sections that by their nature should survive termination (data handling at the end of your account, limitation of liability, governing law) do.

9. Disclaimer of warranties

Ping Bouncer is provided "as is." We don't guarantee it will be uninterrupted, error-free, or that every alert will be routed exactly as expected under all conditions — software has bugs and networks have outages. We work to keep the service reliable, but we don't offer an uptime guarantee unless you have a separate written agreement that says so.

We design Ping Bouncer so that each workspace's alerts are received and processed separately from other customers' alerts, to reduce the chance that one customer's traffic affects another's. That is a design goal, not a warranty. We don't promise any particular latency, throughput, delivery time, or level of isolation, and isolation doesn't extend to the shared infrastructure and third-party providers the service runs on, or to your own sources and destinations. Usage is subject to the limits of your plan (such as event volume, request rates and webhook payload size), and we may throttle or suspend traffic that threatens the service for other customers. Anything stronger needs a separate written agreement.

10. Limitation of liability

To the fullest extent the law allows, Svelte Services LLC won't be liable for indirect, incidental, special, or consequential damages, including lost profits or lost data, arising from your use of Ping Bouncer. Our total liability for any claim relating to the service is limited to the amount you paid us in the 12 months before the claim arose. This applies even if we've been told such damages are possible — alert routing that misses or misdirects a page can be serious, which is exactly why we recommend keeping a fallback path (like your source's native paging) for anything mission-critical.

11. Indemnification

You agree to defend and indemnify us against claims arising from your misuse of the service, your violation of these terms, or content you route through Ping Bouncer that violates someone else's rights.

12. Changes to these terms

We may update these terms as the service evolves. We'll update the date below and, for material changes, notify account holders by email before they take effect.

13. Governing law

These terms are governed by the laws of the United States, without regard to conflict-of-law principles, and any dispute will be resolved in the courts with jurisdiction over Svelte Services LLC.

14. Contact

Svelte Services LLC. Questions about these terms: privacy@pingbouncer.com.