Alert fatigue is one of the most common operational problems in ISP NOCs, and it has a specific cause: when every alert looks the same, engineers stop differentiating between them. A monitoring platform generating 300 alerts per shift at the same visual weight conditions the team to treat them all as background noise, including the ones that warrant immediate action.
Alert taxonomy, the formal classification of alerts into severity tiers with defined response expectations, is the design solution. A well-designed taxonomy means that a Critical alert immediately commands attention because the team knows Critical means subscriber impact right now, while an Informational alert is logged for review but does not interrupt active work. The taxonomy is only valuable if it is consistently applied and if the definitions are tight enough that classification is not subjective.
Defining the Severity Tiers
Four tiers cover the full range of alert types for most ISP operations. The specific labels matter less than the definitions being unambiguous.
Critical is immediate subscriber impact: services unavailable to one or more subscriber groups, upstream link loss, core infrastructure failure, authentication service failure, CGNAT function down. A Critical alert demands an immediate response from an available engineer, and if resolution is not achieved within the response time defined in your SLA, it escalates automatically. Critical alerts are never acknowledged and left: they are owned until resolved.
High is significant risk of subscriber impact or degraded service: link utilisation above 85% of capacity, secondary upstream failure (primary still up), partial authentication failures affecting a subset of subscribers, disk space approaching critical on operational systems, BGP prefix count anomaly. High alerts require a response within 15-30 minutes and a resolution plan within 60 minutes. They may not require immediate interruption of other work but should not sit unacknowledged for the duration of a shift.
Medium is a condition worth tracking that does not yet affect subscribers: link utilisation above 70%, one redundant power supply down (second still running), interface error rates above threshold but within manageable range, backup job failure. Medium alerts are reviewed during normal shift workflow and acted on before the end of the shift if possible.
Low or Informational is conditions that require awareness but no action: successful backup completion, scheduled maintenance activity in progress, interface counters reset. These are logged for operational visibility and reviewed during less busy periods or during handover for situational awareness.
Mapping Specific Alerts to Tiers
The taxonomy is only useful when applied to the specific alerts your monitoring platform generates. For each Zabbix trigger (or equivalent in your NMS), assign a severity tier using the definitions above. This mapping exercise is where most of the operational value is created, and it requires someone with genuine knowledge of the network to do correctly.
Some mappings are obvious: "Core router unreachable" is Critical, "UPS battery at 40%" is Low. Others require judgment: "BGP session to upstream-secondary down" is High if upstream-primary is up and providing full connectivity, but should escalate to Critical automatically if upstream-primary also goes down within the same event window.
The Zabbix severity levels (Not Classified, Information, Warning, Average, High, Disaster) map imperfectly to this four-tier taxonomy, which is why the mapping exercise is necessary rather than relying on default Zabbix severity labels. Map Zabbix Disaster and High to Critical and High in your taxonomy, Warning and Average to Medium, and Information to Low or Informational. Review each trigger individually: the default Zabbix severity for many triggers reflects generic thresholds rather than ISP-specific criticality.
Suppression and Dependency
Alert suppression prevents child alerts from flooding the NOC when a parent condition already explains them. A router that goes offline will generate alerts for every interface, every service, and every host reachable only through that router. If the parent alert (router unreachable) is already being actioned, the child alerts add no information and significantly increase noise.
Configure dependency trees in your NMS: child hosts and services that are only reachable through a parent device should be suppressed when the parent is in a Critical or High state. In Zabbix, this is configured through the trigger dependency feature.
The Review Cadence for Taxonomy Maintenance
An alert taxonomy is not a static document. As the network grows, new device types are added, thresholds that were appropriate at launch become obsolete, and new alert categories emerge. Review the taxonomy quarterly: look at the volume of alerts per tier, identify any tiers that are generating so many alerts that they are being ignored (which means the threshold or classification needs adjustment), and review any alerts that have fired Critical but turned out to be non-impacting (which means the trigger condition is wrong).
For AI-assisted classification that handles the routine triage layer so engineers only see alerts that have been filtered to genuinely needing human attention, NOC Intelligence sits between your NMS and your NOC team. For the full NOC monitoring stack design including alert taxonomy development as a structured deliverable, NOC Enablement & Monitoring covers the end-to-end operational design. For documenting your taxonomy as a formal runbook, RunBook AI generates structured documentation from the taxonomy design you have already done.