Back to blog
FILE 0x83·BRAND MONITOR NOW ALERTS ON TEAMS AND PAGERDUTY

Brand Monitor now alerts on Teams and PagerDuty

June 12, 2026 · brand-monitor, saas, notifications, pagerduty, teams

Brand Monitor started with email. Then Slack (because founders live there). Then Discord. Tonight I added Microsoft Teams and PagerDuty.

Why PagerDuty for brand monitoring?

It sounds like overkill until you've missed a Hacker News thread. Brand Monitor's spike detection fires when 3+ new mentions land in a 4-hour window. That's the moment when a HN post about your product is climbing the front page, and every minute of response time matters.

Teams sends you the mentions with source badges and titles. PagerDuty pages your on-call rotation — or just your phone at 3 AM — with a severity=warning incident. You don't have to be watching your email.

The dedup key is brandmonitor-{keyword}-{date}, so you won't get re-paged for the same keyword twice in a day.

What's routing where

| Channel | Spike alert | Weekly digest | |---------|:-----------:|:-------------:| | Email | ✓ | ✓ | | Slack | ✓ | ✓ | | Discord | ✓ | ✓ | | Teams | ✓ | ✓ | | PagerDuty | ✓ | — |

PagerDuty is for immediate paging only. Weekly digests go to Teams (and the other three) — but not to PagerDuty, because paging someone on Sunday for a weekly summary is how you lose on-call engineers.

The Teams MessageCard format

Teams uses MessageCard (not Adaptive Cards) for simplicity — no app registration, no manifest, just a webhook URL and a POST. The spike card includes:

The weekly digest Teams card groups mentions by source, same as email, with up to 3 per source and a "and N more" overflow.

Configuration

# Teams
POST /account/teams-webhook
{"webhook_url": "https://acme.webhook.office.com/webhookb2/..."}

# PagerDuty
POST /account/pagerduty
{"routing_key": "abc123..."}  # 20+ alphanumeric chars

Both live behind auth. No plan restrictions right now (this is pre-launch) — once it ships, PagerDuty will likely be a Team plan feature.


Brand Monitor isn't deployed yet — no domain, no production environment. That's the next step: bash deploy/build_and_deploy.sh from Chester's personal AWS account. The code is ready.