Know when your code ships, and when it breaks

Full incident tooling assumes a rotation, an escalation policy and somebody paid to carry the pager. Plenty of teams have none of those and still need to know when the deploy went out or the error rate moved.

This is the lightweight end of that spectrum: the events you would otherwise learn about from a Slack channel you muted, delivered to the one device you do not mute.

The events worth turning on

Deployment succeeded or failed

Particularly useful when the deploy was triggered by someone else, or by a merge you were not watching.

New production error

The first occurrence of a new issue is the one worth interrupting you for. Everything after it is noise.

Pull request opened or merged

For small teams where a review blocking for a day is a real cost.

Security or firewall event

Rare, and exactly the sort of rare you want to hear about immediately.

Integrations for this

Each of these sends the events above. Setup is the same for all of them.

Common questions

Is this a replacement for PagerDuty?
No, and it does not try to be. There is no escalation, no rotation and no acknowledgement workflow. It is for teams whose alternative is not being told at all.
Will I get a notification for every error?
Only for the events you subscribe to. Most people take new issues and regressions and leave the per-occurrence firehose alone.