The First Building Block of Effective Incident Management
In any incident management system, the first point of failure is consistently the same: the incident doesn't reach the right team — or reaches it too late. Even with highly skilled engineers, poor initial routing leads to:
- unnecessary response delays
- manual handoffs
- loss of context
- and ultimately, a higher MTTR (Mean Time to Resolve)
This structural problem is exactly what we designed automatic routing rules in Astry to solve.
Deterministic Routing
In Astry, routing rules are defined at the Organisation level — that is, at the level of your company as a whole. They represent the highest routing layer and are evaluated first, before any other logic.
Each rule determines which team an incident should be directed to, based on:
- the tags attached to the incident (technical, functional, business, application, domain…)
- the priority of the incident
Example of a routing rule definition.
The system is intentionally simple. Rules are:
- ordered
- explicit
- evaluated deterministically
This makes it possible to turn a business or technical signal (tags + priority) into an immediate operational decision.
Why This Routing Layer Is Fundamental
From a technical standpoint, this first routing layer has a clear objective: eliminate any ambiguity at the moment an incident is created. The benefits are:
- Elimination of the manual triage phase
- Reduced qualification time
- Fewer incorrect escalations
- Standardised incident flows (including outside business hours)
It is also an essential prerequisite for effectively automating the rest of the incident chain.
Multiple Routing Layers, from Macro to Micro
Routing rules are only the first step. Once an incident has been assigned to the right team, Astry automatically continues with:
- The on-call schedule, which identifies the right person within the team (based on rotations, time slots, etc.)
- Then the notification strategies — individual to each person — which select the notification channel (SMS, Teams call, Email, etc.) based on the time of day, rules, and incident context.
Routing thus becomes hierarchical and transparent:
- Organisation → Team (via organisation-level routing rules)
- Team → Person (via the team's on-call schedule)
- Person → Notification channel (via the on-call person's notification strategy)
A Configuration Built to Scale
Routing rules are configurable directly in the Astry web interface:
- no complex scripts
- with a clear view of evaluation order
Example of routing rule ordering.
Conclusion
A misrouted incident is an incident that's already behind. By structuring routing from the highest level, Astry enables IT teams to:
- respond faster
- make their processes more reliable
- and lay the groundwork for truly industrialised incident management
If automatic routing and on-call management are topics you'd like to explore further, feel free to try Astry for free or reach out to us to discuss your needs.