Not sure what “normal” looks like on your network? A network baseline is a snapshot of performance when everything works, and you build it by measuring key metrics over a typical week or more.
| Item | Value |
|---|---|
| Suggested observation period (OpenNMS) | Preferably a week, or up to a month |
| Paessler’s range for a capture window | A typical day, week, or month |
| Core metrics to record | Bandwidth usage, latency, throughput, packet loss |
| Baseline scope | One baseline per site, not copied from headquarters to a branch office |
| Paessler guide last updated | March 23, 2026 |
Figures come from OpenNMS documentation and Paessler’s baselining guide. They can change, so check the sources before you rely on them.
What a network baseline actually is
A baseline is, in Paessler’s words, “a snapshot of your network when things are running normally”. It records how your devices and links behave under ordinary load, so you have something to compare against later.
Without it, a complaint such as “the network feels slow” has no reference point. You cannot tell whether a link running at a given level is healthy or in trouble, because you never recorded what healthy looks like.
Baselines are the foundation of broader network monitoring, since every comparison and every threshold depends on knowing the usual range.
A baseline is also not a single number. It is a set of ranges that change by hour, by weekday and by site, and the useful question is always whether today’s reading sits inside the range you would expect for this moment.
Which metrics to capture
Start with a short list rather than everything your tools can poll. Paessler names bandwidth usage, latency, throughput and packet loss, “whatever matters for your setup”.
- Bandwidth usage: interface utilisation on uplinks and busy switch ports, across different times of day.
- Latency: round-trip times to key services and between sites when things run smoothly.
- Throughput: the data actually moving, as opposed to link capacity.
- Packet loss: usually near zero when healthy, so any rise stands out.
- Device load: CPU and memory on routers and switches under normal traffic.
Add traffic flow details later, such as where data goes to and from. Paessler notes a baseline should cover how routers and switches behave under normal load and where your data flows.
Choose metrics by asking what users would complain about. If people notice slow file transfers, throughput and latency matter. If they notice video calls breaking up, packet loss deserves a closer look.
How long to collect data
A single quiet afternoon is not a baseline. OpenNMS advises that once the environment is configured you let it run for a bit, “preferably a week, or up to a month”.
The longer window matters because networks have rhythms. Mornings, month-end jobs, backups and weekends all produce different readings, and a short sample misses them.
Paessler frames the same idea more loosely, describing a typical day, week, or month when everything works fine. The common thread is that the period must be representative, not merely long.
Steps to build your baseline
- Pick the scope. Choose the sites, links and devices that matter most to users.
- Confirm the network is healthy. A baseline taken during an outage records the problem as normal.
- Poll consistently. Use the same interval and the same metrics throughout the collection period.
- Observe for a week or longer. Let the data accumulate without changing thresholds.
- Summarise the ranges. Note typical, peak and quiet values for each hour and weekday.
- Record it. Save the figures with the date and any known changes, so you can compare later.
OpenNMS says the observation also helps you judge how effective your notification rules are and when your network reaches peak operating times.
Step two deserves care. Paessler points out that if you see consistent packet loss while baselining, you already have problems to fix, so repair those first and then start the clock again.
Reading the data without fooling yourself
Averages hide a lot. A link that averages moderate use may sit idle overnight and saturate for an hour at midday, so keep peaks and quiet periods next to the mean.
Look for patterns that repeat. A spike every night at the same time is part of normal behaviour, probably a backup or a scheduled job, and it belongs in the baseline rather than in an incident report.
Write down what you learn about each pattern. A short note such as “nightly backup, expected” saves the next person from chasing a harmless spike.
- Normal range: where the metric usually sits for that hour and weekday.
- Known exceptions: backups, patch windows, reporting runs and similar events.
- Outliers: readings that fit neither, which are the ones worth investigating.
Common mistakes are easy to avoid once you know them. Each one produces a baseline that looks tidy but misleads you later.
- Too short a sample: a few hours cannot show weekly or month-end cycles.
- Baselining a sick network: existing faults become “normal” and never get fixed.
- Changing polling mid-way: different intervals make the early and late data hard to compare.
- Never reviewing it: the network changes, and a stale baseline stops describing it.
Keep the raw history as well as the summary. When someone later asks whether a slowdown is new, you can show the same hour on earlier weeks instead of relying on memory.
Keeping the baseline useful
Paessler learned the hard way that a headquarters baseline does not fit a branch office. Treat each site, and ideally each important link, as its own baseline.
Refresh the numbers after real changes: a new application, a link upgrade, more users. Otherwise the old figures make normal growth look like a fault, or hide a real one.
Once ranges are known, network alerting can fire on deviation from your baseline rather than on guessed fixed numbers. Paessler puts it simply: when something deviates from your baseline, you know immediately.
The same data supports trend work too, and network performance monitoring compares ongoing readings against that same reference.
A simple review habit helps. After any planned change, compare a fresh week of readings with the saved baseline, decide whether the difference is intended, and replace the old figures only if it is.
Share the finished baseline with whoever handles incidents, so everyone agrees on what normal means before the next slowdown arrives.
Keep the process lightweight. A baseline that takes hours of manual work to refresh will be skipped, while one that your monitoring tool collects automatically will stay current with little effort.
Frequently asked questions
How long should I collect data for a network baseline?
Show answer
OpenNMS suggests preferably a week, or up to a month. Paessler describes capturing metrics during a typical day, week, or month when everything works fine.
Which metrics belong in a baseline?
Show answer
Begin with bandwidth, latency, throughput and packet loss, the set Paessler lists. Add device load and traffic flows once those are stable.
Can I reuse one site’s baseline at another?
Show answer
It is risky. Paessler’s author found that applying a headquarters baseline to a branch office went badly, so measure each site separately.
Why take a baseline at all?
Show answer
Because deviations are only visible against a known reference. Without one you are, as Paessler’s author put it, flying blind.
