How Sentinel differs from the tools you already have
Sentinel does one narrow thing. Most of this page is about what the other tools do better, because that is the part you need in order to decide, and a comparison you can falsify in one click costs more trust than it buys.
The one thing Sentinel does
It searches your own resolved incidents for one that looks like the incident in front of you, and shows the action item a person wrote at the time, with the date. That is the product.
What each of these does that Sentinel does not
PagerDuty
Detects, escalates and wakes people up — on-call schedules, overrides, phone calls that keep ringing, escalation policies. Sentinel does none of that and is not trying to: it sits downstream of whatever pages you. PagerDuty also has its own alert grouping, which for many teams is already enough.
Datadog / Grafana / New Relic
They hold the telemetry. Metrics, traces, logs, dashboards, the ability to answer "what was the p99 at 03:14". Sentinel has none of your telemetry and never asks for it — it sees the alert emails you forward and nothing else. If you want to know what actually happened, you go to them, not here.
incident.io / FireHydrant / Rootly
Full incident management: Slack-native declaration, roles, comms templates, status pages, stakeholder updates, retrospectives, and analytics across incidents. They are considerably larger products, they integrate with the tools you already run, and several of them also surface similar past incidents. If you are buying an incident platform, buy one of those.
A wiki of runbooks
A good runbook wiki is better than Sentinel whenever a runbook exists, because a runbook is written deliberately, edited, and covers what to do rather than what someone once did. Sentinel's advantage is only that it is populated as a side effect of closing incidents — the wiki page that nobody wrote is the one it can still show you.
Where Sentinel is genuinely weaker
- It is useless when new. The library is your own history. With no resolved incidents there is nothing to match against, and it will say so, for weeks.
- Lexical matching, not semantic. Two incidents described in different words will not be linked. A team that writes "connection pool exhausted" one month and "DB maxed out" the next will see a miss where a person would see a match.
- Two intake doors and no integrations. A webhook URL and a forwarding email address. No Slack app, no PagerDuty integration, no two-way sync with anything — Sentinel reads what you send it and never reaches into your systems. Nothing is being received at the forwarding address on this deployment yet, so today the webhook is the door that works.
- No paging, no schedules, no status page, no analytics.
- Nobody has run it at scale. It is new. The grouping windows are reasoned choices, not numbers tuned against a year of a large team's alert volume.
When Sentinel is worth having
A small team, alerts already arriving by email, a habit of writing one line about what fixed something, and the specific recurring feeling of "we have seen this before and I cannot remember what we did". It is cheap to try because it needs no access to anything: you forward mail to an address.
No number on this page is a benchmark and none of these products was tested against Sentinel. This is a description of scope, written from each product's own public documentation. Where you find it wrong, it is wrong and we would like to know.