NOC alarm and incident logs for network root-cause AI

Why public log benchmarks do not cover network alarm correlation

Public log datasets are useful for parsing and generic anomaly detection, but they were not collected from network element managers and contain no alarm correlation ground truth. Loghub, the main open collection, provides 19 real-world log datasets from distributed systems, supercomputers and operating systems, and only a minority are labeled [1]. None of them is a carrier alarm stream with topology.

The gap persists in newer work. A 2026 benchmark of LLM-based log anomaly detection still evaluates on a handful of classic datasets, including HDFS, BGL, Thunderbird and Spirit [2], and the LogEval suite reuses the same public logs across parsing and anomaly tasks [3]. Results on those corpora say little about how a model handles a fiber cut that raises hundreds of loss-of-signal alarms across a ring.

Network alarm data differs in three structural ways:

• Stateful, not line-oriented. An alarm is raised, possibly updated in severity, and cleared. Modern alarm models treat alarms as states on resources rather than discrete notifications, so a row-per-line log representation loses the lifecycle.
• Topology-dependent. Whether two alarms share a cause depends on adjacency, shared links, shared power or shared software releases. Without a topology snapshot at the time of the incident, correlation labels cannot be learned or checked.
• Label lives elsewhere. The confirmed cause is usually written in a trouble ticket, a change record or a postmortem, not in the alarm stream itself.

Teams working on software telemetry should compare this page with telemetry aligned with incident labels for root-cause analysis and production log data for log anomaly detection; NOC data is a separate type with its own normalization problems.

What a labeled NOC alarm and incident record contains

A usable record joins four layers: the raw alarm event, its normalized fields, the correlation group, and the linked incident with a confirmed root cause. Each layer comes from a different system, typically an element management system (EMS) or network management system (NMS) for alarms, an inventory or topology database, a fault-management correlation engine, and an ITSM tool for tickets.

Published standards make normalization feasible across vendors; confirm the exact attribute definitions against the current texts. ITU-T X.733 [4] defines the perceived severity scale (critical, major, minor, warning, indeterminate, cleared) and probable cause attributes, and IETF RFC 5674 [5] carries those values into syslog with an enumerated probable cause such as transmissionError. TM Forum's alarm data model groups probable causes under event types such as communications, equipment, environmental, quality of service and processing error alarms, with values consistent with X.733 or 3GPP TS 32.111-2 Annex B. RFC 8632 [6] adds a YANG alarm model with an alarm inventory of every alarm type a device can raise and explicit shelving of suppressed alarms.

Illustrative example: invented to show structure; it does not describe an available dataset.

The correlation_group_id field needs a provenance flag. A group created by the operator's existing correlation engine teaches a model to imitate that engine; a group confirmed by an engineer after resolution teaches the real relationship. Ask for both and keep them distinct.

Where confirmed root causes actually come from

Confirmed root causes almost always come from the incident record, not the alarm feed, so the dataset is only as good as the alarm-to-ticket join. In most NOCs a ticket is opened from one alarm or a correlation group, worked by tier 1 and tier 2 staff, and closed with a resolution code and notes. Major incidents get a postmortem with a written timeline and causal chain.

Common failure modes buyers should check for:

• Resolution-code drift. Closure codes such as "hardware" or "no fault found" are chosen under time pressure. Sample tickets and compare the code with the narrative notes.
• Missing join keys. Tickets opened by phone or email may never reference an alarm ID. Measure the share of tickets with a valid alarm or group link before you agree on scope.
• Post-hoc correlation leakage. If the correlation group was edited after the ticket closed, features computed from it leak the answer into training.
• Change-induced faults. Many network incidents trace to a configuration change or software upgrade. Without change records or maintenance-window flags, a model learns that upgrades cause random alarms.

Related joins appear in telecom network trouble ticket data for troubleshooting agents, and SourceX also covers licensing incident postmortems and ITSM ticket datasets for adjacent use cases.

Building training and evaluation splits from alarm streams

Split by time and by incident, never by individual alarm, or the model will see sibling alarms from the same outage in both training and test sets. A single power failure at a hub site can produce thousands of alarms that share one cause; random row-level splits make correlation look trivially easy.

Practical split rules:

1. Hold out whole calendar windows (for example, the final quarter of the export) as the test period.
2. Keep every alarm in a correlation group on the same side of the split.
3. Record topology snapshots per window, since network changes between training and test periods are part of the real difficulty.
4. Report results separately for storms (large groups), single-alarm incidents and change-related incidents.

For NOC agent evaluation, build tasks from resolved incidents: give the agent the alarm window, topology and runbook, then score whether it names the root element and cause category that the ticket confirms. Time-aligned alarm, metric and note data is discussed further in paired time-series and text data.

Security and privacy limits on network data

Topology, element names, IP address plans and circuit IDs are sensitive infrastructure details, so expect suppliers to generalize or tokenize them and to restrict access. Hostnames often encode site codes and city names, and circuit IDs can reveal enterprise customers. Tokenize consistently so that the same element maps to the same token across alarms, topology and tickets, otherwise joins break.

Ticket notes carry personal data and customer details: technician names, callback numbers, customer account numbers and street addresses for site visits. SourceX removes or replaces personal details such as names, emails, phones and account numbers before delivery, records the method, and checks a sample, though no method is perfect. Rare events and small sites can still act as indirect identifiers, a risk covered in indirect identifiers in business text.

Requirements checklist for licensing NOC alarm data

A NOC data license should define the alarm schema, the label source, the join coverage and the security treatment before any data moves. Use this checklist when you write a request or review a supplier's sample.

Illustrative example: invented to show structure; it does not describe an available dataset.

The rights row matters because alarm data may sit in a vendor-operated managed service or an outsourced NOC. Ask who owns the export and whether any contract limits reuse; see chain of title for AI training data.

How SourceX approaches NOC alarm and incident data

SourceX sources operational datasets from US companies on request and manages the licensing process; categories such as network alarm data are not held in stock, and a request does not guarantee a match. Buyers describe the data they need, and SourceX looks for US businesses that hold it, with every release approved by the supplying company.

Each dataset is reviewed for ownership and consents and delivered under a license that defines the records, uses, term and delivery. Delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval. Telecom buyers can also see buyers by industry: telecom services, training data for IT operations agents, and the wider industry-specific operational data guide. To describe a specific alarm and ticket scope, use the SourceX buyer request page.

Request network alarm data for root-cause AI

SourceX finds US companies that hold the operational data you describe, assesses data and licensing permissions, and manages the license and ongoing purchases; nothing is contracted until a supplier agrees. Describe the alarm, topology and ticket fields you need on the SourceX buyers page.