What Is a NOC? What It Does and How It Differs from a SOC
A NOC watches infrastructure 24/7 and is first to respond when something breaks. Its duties, escalation tiers, metrics and the difference from a SOC.

Short answer: A NOC (network operations center) is the team that watches an organization's network, servers and cloud resources around the clock, responds first when an outage or slowdown begins, and hands anything it cannot fix to the right specialist. Its job is to keep services up. That is also the difference from a SOC: a NOC asks "is it working?", a SOC asks "is someone attacking it?"
What does NOC stand for?
NOC stands for network operations center. IBM describes it as a central location where computer, telecommunications and satellite networks are monitored and managed 24/7, and calls it the first line of defense against network disruptions.
Don't read too much into the word "network". A modern NOC watches far more than switches and routers: servers, storage, the virtualization layer, cloud resources and the availability of the applications on top. In IT, that is what a NOC means today: the operations team that watches the whole infrastructure and stands on call for it.
What does a NOC do?
Put the definitions from AWS and IBM together and the work falls into five areas:
- Monitoring and alerting. Connectivity, latency, packet loss, jitter, CPU, memory, disk usage and service health are measured continuously. When a value leaves its accepted range, an alert fires.
- Incident management. The alert is verified, the location and cause of the problem are found, and the problem is either fixed or escalated. Some responses are automatic, such as restarting a service or rolling back to the last working state.
- Maintenance and change. Patches, version upgrades and planned maintenance windows run through the NOC's calendar.
- Backup monitoring. The NOC checks that backup jobs actually completed. A failed backup is an incident to catch before a disaster, not after.
- Capacity planning and reporting. Usage trends are tracked so that capacity is added before a bottleneck forms, and availability, incidents and capacity are reported on a regular schedule.
How does a NOC work?
It helps to think of a NOC in four layers, and AWS draws the same lines:
- Collection. Logs, metrics and telemetry are gathered in one place and normalized. Our piece on what a log is covers why they are kept.
- Analysis. Alerts are correlated with each other. A dependency map shows which other services a failure will affect, so twenty alerts from one root cause are seen as one incident.
- Response. An automated action runs or the on-call engineer is paged. Every incident gets a ticket that stays open until it is resolved.
- Escalation and communication. Anything that cannot be resolved moves up a tier, affected teams are informed, and a report is written once the incident is closed.
Most NOCs run three tiers. Tier 1 watches, makes the first diagnosis and fixes known problems from the runbook. Tier 2 does deeper diagnosis. Tier 3 takes problems that touch the architecture, a vendor or an application team. Who steps in at which threshold should be written down in advance; we give a template in our incident escalation matrix piece.
A sample night (this is an example; thresholds, roles and timings differ between organizations): at 03:17 a database server's disk passes 90% full. The alert lands with Tier 1. The on-call engineer sees that old log files were never cleaned up, frees space with the runbook step and closes the ticket. The next day the team looks at why it happened again and fixes the log rotation setting. Had the alert waited until morning, the database would have stopped writing the moment the disk filled up.
NOC vs SOC: what is the difference?
| NOC | SOC | |
|---|---|---|
| The question it asks | Is the service working? | Is someone attacking it? |
| Focus | Availability and performance | Threat detection and response |
| Where alerts come from | Threshold breaches, health checks, outages | Correlation rules, suspicious behavior |
| Main tools | Monitoring system, APM, ITSM | SIEM, EDR/XDR, SOAR |
| Typical incident | Full disk, dropped link, crashed service | Suspicious login, malware, data leak |
| Measure of success | Availability, MTTR | Time to detect and respond |
One does not replace the other. AWS notes that the two overlap in places but use different technologies and separate escalation paths. In practice the same event can land on both desks: a DDoS attack looks like a bandwidth problem to the NOC and like an attack to the SOC. That is why both teams need to see the same incident record, and how they hand work to each other needs to be written down. We cover the SOC side, together with SIEM, in what SIEM and a SOC are.
Which metrics does a NOC track?
- Availability: the share of time a service is up. The target comes from the SLA; our uptime piece shows how it is calculated.
- MTTA (mean time to acknowledge): the average time between an alert firing and a person taking ownership of it. It is the most honest measure of whether anyone is actually watching.
- MTTR (mean time to repair): the average time from the start of an outage to the service being restored.
- False alarm rate: the share of alerts that do not correspond to a real problem. As it grows, the team stops trusting its alerts.
- Repeat incidents: incidents that come back from the same root cause. If this number does not fall, the NOC is closing incidents without solving problems. ITIL draws this line as incident management versus problem management.
Targets depend on the organization's SLA; there is no single right number. What matters is that these measures are calculated and reported the same way every month.
Your own NOC or a managed NOC?
The decision starts with a staffing calculation. A year has 8,760 hours; after leave, public holidays and training, one person works roughly 1,800 hours a year. Keeping one monitoring seat filled all year therefore takes about five people; the full calculation is in the staffing section of our SIEM and SOC piece. Add tool licenses, training and the fatigue of the night shift.
According to IBM, running your own NOC takes significant resources: the investment can pay off for large enterprises and communications companies that want to keep control, while for organizations such as government agencies and universities outsourcing can be more cost-effective. There is also a middle model, where your own team covers business hours and a provider covers nights and weekends. Weigh four things:
- The size and spread of the infrastructure: how many locations, environments and cloud accounts
- Whether your team has the capacity to stand on call
- The availability and response time you have promised your own customers in their SLAs
- Where the data lives: monitoring produces logs, and logs can contain personal data
Questions to ask a NOC provider
- Who looks at an alert: an engineer, or an automated notification that lands in your inbox?
- Is there a written escalation matrix? Who makes the call at 3 a.m.?
- Can they work with your current monitoring tool, or do they rebuild everything?
- Are MTTA and MTTR in the contract, and are they reported every month?
- What does the monthly report contain: an availability percentage only, or root causes and recommendations as well?
- Where is the monitoring data stored?
How Eclit runs its NOC
Eclit's 24/7 monitoring and NOC service covers servers, network, storage, virtualization and cloud (AWS, Azure, GCP). Every alert is reviewed by the on-call engineer; false alarms are filtered out, real problems are fixed, and monthly reporting and capacity planning are part of the service. Security incidents go to a separate SOC service. Eclit manages more than 20,000 servers today.
Frequently asked questions
What does NOC mean? Network operations center: the team and facility that watches an organization's IT infrastructure 24/7 and responds first to outages.
What does a NOC engineer do? Watches the alerts on the monitoring screens, verifies the problem, takes the first action from the runbook, escalates what they cannot fix and records the incident. With seniority the work shifts from diagnosis to root cause analysis, better monitoring rules and automation.
Can the NOC and the SOC be the same team? In small organizations the two jobs can sit with one team, and some providers run NOC and SOC from the same center. The skills and tools differ, though: the NOC looks at availability, the SOC at threats. Even in one team, the two need separate escalation paths.
Is 24/7 monitoring the same as a NOC? No. Monitoring is an activity; a NOC is the team and process that carries it out. If nobody answers an alarm at night, you have 24/7 monitoring but no NOC.
What tools does a NOC use? Infrastructure and network monitoring (on the open source side, tools such as Zabbix or Prometheus with Grafana), application performance monitoring (APM), log management, an ITSM platform for incident records and an on-call system that pages the person on duty. The tool comes second; what matters is who an alert goes to and by which rule. We walk through a Prometheus and Grafana setup in our observability piece.
Sources
- IBM, What is a network operations center (NOC)?: definition, duties, in-house versus outsourced
- AWS, What is a Network Operations Center?: layers, escalation tiers and the difference from a SOC
- How we run this layer: 24/7 monitoring and NOC service