Platform
Seven stages, and CallHeim is different in the three before somebody’s phone rings — that is where the decisions live and where every rule is published. It is complete in the four after.
The CallHeim loop
Pick a stage to see what it does and the threshold it does it with.
Before the page
where CallHeim is different
After the page
response and closure
Duplicates collapse, flapping series stop paging, related alerts group.
Fingerprint dedup inside 300s, flap collapse at 4 transitions / 600s, title correlation at Jaccard ≥ 0.6.
12 alerts in, 1 incident out
Ingest · Reduce · Decide
Everything between a webhook arriving and a person's phone lighting up.
Alerts arrive over HTTPS from your monitoring, CI and cloud tools.
In the console: Integrations · Catalog
REDUCERepeats collapse inside a five-minute window; flapping and related alerts group by published rules.
In the console: Noise Rules · Maintenance
DECIDEThe source’s service picks the escalation policy. CallHeim suggests a severity; a person applies it.
In the console: Orchestration Rules · Services
An alert passes through these before it is allowed to become an incident. Orchestration rules run first, and tenant threshold rules can add more. Each check has a threshold, and every threshold below is published.
The decision pipeline. By default seven ordered checks run on every alert; orchestration rules run before them and tenant threshold rules can add more. Most checks divert the alert out of the sequence — a flapping series with nothing open to join is the one exception that still creates an incident.
Maintenance window
Suppress if a window covering this service, team or the whole workspace is open right now.
active windowOutcome: suppress
Suppress rules
Suppress if any tenant Noise Rule matches the alert.
rule matchOutcome: suppress
Fingerprint dedup
Attach to the open incident that already owns this fingerprint, while repeats keep arriving. The fingerprint is the tenant, the source, and the alert’s dedup key or identity — falling back to its title. The service is not part of it.
300s sliding windowOutcome: attach
Flap collapse
A series that keeps changing state attaches to the open incident instead of paging again. With nothing open to join, it still opens an incident.
4 changes / 600s (fixed)Outcome: group
Title correlation
Group with an open, still-Triggered alert from the same source and the same service when their titles overlap enough.
Jaccard ≥ 0.6 default, 600sOutcome: group
Group rules
Apply the tenant’s own grouping rules over the window.
600s windowOutcome: group
Create incident
Nothing above matched: open the incident with the source’s severity (or the severity an orchestration rule sets), pick the Escalation Policy for the service, and page.
elseOutcome: create
Defaults shown above. Orchestration rules run first and tenant threshold rules can add further steps.
Example · the pipeline's own mechanics
One alert, walked through the checks above, with the numbers those checks actually use.
01 · A webhook arrives
{
"alert_type": "error",
"title": "checkout-api p99 latency > 2s",
"host": "checkout-api-canary",
}02 · The alert gets a fingerprint
Tenant, source and the alert’s dedup key or identity, falling back to its title. The service is not an input.
Resets on every new repeat.
03 · Duplicates collapse, grouping does not cross sources
Attach to the open incident; no new page.
Same source, same service, still Triggered, within 600s. Never across sources.
04 · Severity is the source's, plus a suggestion
Mapped from what Datadog sent (or an orchestration override).
A separate suggestion from a keyword ruleset and your resolved incidents. A person applies it; it never changes severity on its own.
05 · Routed and paged
checkout-api p99 latency > 2s
How incident severity levels work →What an escalation policy is →
Page
Escalation runs on an AWS Step Functions state machine: an unanswered tier times out and advances to the next tier or the fallback.
Tier 1
The responder on call right now, paged on their own notification order.
Tier 1
No acknowledgement → tier 2
Still nothing → the tier chain repeats
One fallback target, once
The walk stops
Respond · Resolve · Learn
This half is table stakes, and CallHeim treats it that way: no unusual claims, just a timeline, roles and analytics.
Tiers and timeouts advance to a mandatory fallback until someone acknowledges. E-mail paging today, in early access.
Escalation Policies · Schedules
RESPONDAcknowledge, comment and work the incident on a timeline with no edit or delete.
Incidents · Timeline
RESOLVETriggered → Acknowledged → Resolved → Closed, with a public status page your team updates.
Incidents · Status Page
LEARNMTTA and MTTR from each incident’s own timestamps, plus a published on-call fatigue score.
Insights · Analytics
Pricing
Alerting, on-call, escalation, noise reduction, incident response, public status pages and core analytics are included at every tier.
Some features are tied to plan: the REST incident API and related-incident insights on Pro and above; email-to-alert (per-workspace inbound alert e-mail addresses) on Trial, Business and Enterprise, not Starter or Pro.
CallHeim helps teams stay in control when critical systems are not. Pick the plan that fits, connect one source, and send yourself a page.
Early access · every workspace starts with a 14-day trial for up to 5 seats, no card required