Alerting
Everything HeaderHawk notices reaches a person through one set of rules: which kinds of event, on which sites, to which destinations, now or in a digest. A problem reported widely alerts straight away. One reported once by one browser waits for the digest, and a report from an extension or a bot never alerts.
Every delivery is recorded, so you can show who was told and when.
- Plans
- Email on every plan; Slack and webhooks on the Team plan and above
- In the dashboard
- Alerts
What's at stake
An alert is only useful if somebody still reads them
Browser reports are noisy. Extensions, crawlers and one confused browser all report. Forward every one and the channel is muted within a week, including on the day it matters.
Alert fatigue
The important one arrives in a pile of trivial ones
A channel that fires on every report trains the team to mute it, and the alert about a new script on the checkout gets read on Monday with the rest.
Wrong audience
Not everything belongs in the same channel
A policy change on the marketing site and a new script on the payment page need different urgency, and different people.
No trail
"Were we told?" has no answer
After an incident, or in front of an assessor, the question is who was alerted and when. An unrecorded notification cannot answer it.
What it does
Scored, routed, recorded
Rules by type, site and page
A rule names the kinds of event it hears and the sites it covers, all of them or the ones you choose. Choosing all of them includes ones added later. On the Professional and Business plans, a rule can listen to payment pages only, so checkout alerts reach the checkout's owners.
Every plan
New CSP issue
New data destination
New framed origin
CSP policy changed
New security policy issue
Integrity check blocked a resource
Network errors or crashes spiked
Deprecated feature due for removal
The Professional and Business plans
Security header changed
Scan grade dropped
Page scan failing
New script on a payment page
Pinned script changed
Rejected script seen again
Script gone from a payment page
Script moved to another origin
Script has a known vulnerabilityScored before it is sent
Violations gather in short windows, and each window is scored by how widely it was reported. Two browser families, or twenty reports from one, count as a real problem and alert at once. Anything quieter goes to the next daily or weekly digest. Reports classified as noise, from extensions, harmless URL schemes and known bots, never count towards the score.
Now, or in a digest
A rule delivers immediately, or as a daily or weekly digest, one per destination. A new issue is sent once, and while it lasts it goes into the digest. It is sent again only if it comes back after you mark it fixed. Mark it expected and it never alerts. Other alerts have a cooldown, 24 hours unless you change it. For the first week after a security policy type is switched on for a site, its new issues go to the digest instead, where one covers the site, because that week reports everything already true of your pages at once. Monday's digest also lists the deprecated features your pages use that are due for removal within 60 days.
Email, Slack and signed webhooks
Email goes to any address that has confirmed it wants the alerts. Slack posts to the channel you choose. A webhook receives JSON signed with HMAC SHA-256 in an X-HeaderHawk-Signature header, using a secret only you and HeaderHawk hold, so your receiver can tell a real alert from a forged one. Every destination can be sent a test.
A record of every delivery
The Alerts section lists every alert sent, with its destination, site and event, and whether it was delivered. It is filterable, kept as long as your plan keeps reports, and it answers an assessor who asks how a change would have reached somebody.
How it runs
Many sources, one router.
Each source raises a candidate, and one router applies your rules, the cooldowns and your plan. Every kind of alert shares the same destinations, digests and history, and a rule listening for every kind covers one added next month.
- Reports as they arrive, covering CSP and security policy violations, enforced integrity blocks, and spikes in network errors and crashes.
- The policies those reports quote, when a new one appears.
- The daily scans of the pages you mark, on the Professional and Business plans.
- The scripts on your payment pages, and the advisories published against the library versions your scripts run, on the same plans.
Scope
One layer, and where it stops
HeaderHawk decides what is worth telling somebody and records that it did. What happens next belongs to the tools your team already runs, and the webhook gets it there.
| Alerting does | It does not replace |
|---|---|
| Routes every kind of event through rules you write once | An on-call tool's escalation and rotas. Send the webhook there |
| Scores violation alerts by how widely they were reported | A per-rule volume setting. Urgency comes from how widely a problem was reported, not from a number you choose |
| Delivers by email, Slack or signed webhook, now or in a digest | Your SIEM. Alerts are events about your pages, not a log stream |
| Records every delivery for later |
Alerts your team will still read
Email alerts are on every plan, the Free plan included. Slack and webhooks start on the Team plan.