How to find the cause when the network is slow in the morning

When the network is slow in the morning, the cause almost always lives in a schedule, even when nobody remembers what was scheduled. Employee logons, Group Policy processing, file synchronization, updates, antivirus scans, backups, and the first heavy queries to business systems all meet in the same window. Replacing a switch on a hunch is expensive and usually useless.

A diagnosis must connect the user-visible delay to a specific resource and a specific flow on one timeline. You need data from before, during, and after the incident: application latency, interface utilization, loss and discards, server CPU, memory and disk state, plus job logs. One morning snapshot shows correlation. A repeat on a second day and a controlled change establish causation.

Catch the morning incident before the first call

You cannot investigate recurring degradation from user accounts at ten o'clock, after it has ended. Start collection at least half an hour before the problem normally begins and keep it running into a stable period. A 15-second interval works for the broad picture; 1-5 seconds helps on interfaces with short bursts if the monitoring system can handle the volume.

First, define the symptom as a measurable operation. "Everything is slow" is not usable. Choose two or three tests that reproduce the complaint: time from logon to a usable desktop, opening one file of a known size, a response from a specific internal web method, a database connection, or loading a small page without external resources. Run them on a schedule from the same wired control workstation.

Every test needs a start time, end time, result, and destination address. If a web application opens in 18 seconds, split the path into DNS, TCP connection setup, TLS, and time to first byte. Slow DNS points somewhere different from a fast TCP connection followed by a long wait for the first byte. The user sees one pause, but the engineer must see the stage.

Collect four layers at the same time:

• client: logon time, DNS, TCP, and the application operation;
• network: bytes, packets, queues, discards, errors, and retransmissions;
• server: CPU, memory, disk latency, network interface, and request queue;
• schedule: backups, updates, scans, synchronization, and batch jobs.

Do not begin with a permanent capture of all traffic on every port. That creates a mountain of data and risks capturing content you do not need. Counters and synthetic checks narrow down the window and segment. Use a short packet trace on a defined pair of hosts once you know the question that the trace needs to answer.

One timeline eliminates half the false theories

Put every source on one time scale or nearby events will look simultaneous. Check clock synchronization on clients, servers, hypervisors, network equipment, and the backup system. Record the time zone and do not mix local time with UTC without an explicit conversion.

Build a table with one-minute or shorter intervals: active user count, duration of the control operation, inbound and outbound link utilization, increase in discards, TCP retransmits, CPU and disk latency on the target server, and the start and end of each job. The change in a counter over the interval matters, not the accumulated value since the switch was installed. A million old errors do not explain this morning; one hundred new discards in the problem minute explain much more.

Mark boundaries, not only peaks. If a backup begins at 08:00, the link fills at 08:03, retransmissions rise at 08:04, and the application slows at 08:05, the theory is plausible. If the application is already slow at 07:55, the backup cannot be the first cause, although it may make the situation worse later.

Compare three windows: a quiet period, the problem morning, and a similar morning without the suspected job. Comparing Monday with Sunday often misleads because both the user count and the batch workload change. It is better to move one job in an approved test window or cap its rate while leaving the rest of the load unchanged.

Record changes in a separate column. Restarting a service, switching an access point, or manually stopping a backup changes the system under observation. Without that record, a graph can show a "self-recovery" that an administrator actually caused.

A logon storm creates several different loads

A morning logon does not load only the domain controller. A workstation obtains an address, finds DNS and a domain controller, validates credentials, applies policies, runs scripts, maps network drives, reads a profile, and starts startup programs. A hundred near-simultaneous logons turn every small operation into a wave of DNS, LDAP, Kerberos, SMB, and profile-storage requests.

That is why average backbone utilization of 30 percent does not clear the network. Short microbursts can fill an output queue between two polling samples, while a slow domain controller can delay logon on a free link. Look at destinations and protocols, port queues, and the resources of the services involved in logon.

In a Windows environment, start with the Microsoft-Windows-GroupPolicy/Operational log on the control workstation. Microsoft's Group Policy troubleshooting guidance recommends tying events from one policy application together by ActivityID and dividing processing into pre-processing, processing, and post-processing phases. That is better than hunting for one red event: a long successful phase can also cause the delay.

Check which logon scripts copy files, which GPOs install packages, which drives get mapped, and where roaming profiles live. One script that compares a large directory over the WAN at every logon can create a regular wave without an obvious error. Measure it separately with a cold cache and a warm cache.

On domain controllers, correlate authentication requests with CPU, disk, and network interface activity. In Windows Server 2025, Microsoft added separate DC Locator and LDAP client counters, including successful and failed domain controller lookup latency, new requests, pending responses, and average response time. On earlier versions, use Netlogon, Directory Service, and DNS logs plus ordinary system counters instead of inventing metrics that do not exist.

A logon storm has a recognizable set of signs: logon count rises sharply, requests to DNS and domain controllers arrive in the same wave, the profile file server reads many small files, and the problem fades after the first user session finishes. If a second logon on the same computer is fast because of caching, that is another clue, but it does not prove that the network is at fault.

The popular advice to "solve the problem by adding bandwidth" is often wrong. A wider link will not speed up an overloaded DNS service, domain controller disk, or sequential logon script. Name the resource whose queue is growing before changing capacity.

Updates and backups reveal themselves by direction

Background jobs differ by direction, destination addresses, and disk load. Update deployment usually creates a large outbound flow from a local repository to many clients, or a large inbound flow over the internet link when clients download packages externally. A backup more often reads production servers and writes to a repository, so it loads the network, source disk, and target storage at once.

Check more than the central schedule. Clients may use their own random delays, retry after being powered off overnight, or run "at the first opportunity" so a missed job begins immediately after startup. An administrator can truthfully say that updates are scheduled for the night while the graph still shows a morning wave.

Correlate five signs:

• the largest senders and receivers in the problem window;
• the ratio of inbound to outbound traffic on the constrained interface;
• the actual job start time and volume, not the planned values;
• queue and latency on the source and repository disks;
• rate limits, parallel stream count, and retry activity.

If backup traffic fills the link, temporarily limiting its rate should reduce application latency in the next comparable window. If traffic drops but the application stays slow, look for a shared disk, overloaded proxy, server CPU, or another dependent resource. This distinction matters: a job that coincides with the incident can be a load without being the bottleneck.

Do not move all maintenance to 02:00 without checking. Full backups, replication, database exports, antivirus, and storage maintenance may already meet at night. Spread jobs according to their dependencies, set an acceptable bandwidth, and leave headroom before the working day. A missed job needs a controlled retry window, not a rule to start immediately after boot.

For every heavy job, record its owner, server, source, destination, normal volume, concurrency limit, and acceptable window. This simple register often reveals two independent schedules that nobody had previously viewed together.

Check DNS and the proxies used for updates separately. A wave of clients may leave the link below capacity while exhausting concurrent connections, worker threads, or cache capacity in an intermediary service. Bytes remain moderate, but connection setup or DNS response time rises. Compare a direct control operation with the same operation through the normal intermediary and monitor its queues.

Normalize traffic against the interface's real speed. Multiply bytes per second by eight to compare them with bits per second, while protocol overhead and measurement details leave a small gap between the calculation and the nominal rate. On an aggregated link, inspect utilization and discards on every physical member: hashing can place one large flow on one link while the aggregate graph looks free.

NetFlow, IPFIX, or sFlow data helps name the largest address pairs, ports, and directions. It shows who used the bandwidth but does not replace interface counters: sampling can smooth a short burst, and a flow record does not always explain a hardware discard. Use flows for attribution, queues to prove congestion, and server metrics to verify the impact.

Compare useful work volume with the job's behavior. If a daily incremental backup suddenly reads the full data set, find out whether the chain was reset, change tracking stopped, or reindexing began. A morning spike can be the result of a failure the previous night: one attempt fails, clients power on, and the system launches a retry. A log with status, processed volume, and retry reason tells you more than a schedule entry.

After limiting a job, confirm more than the disappearance of complaints. The job must still finish within its acceptable window. A limit that pushes the backup through the entire working day merely spreads the competition. Choose a rate and concurrency level that keep interactive operations at baseline latency while meeting the background task's recovery-time requirement.

A congested link shows queues and loss

High utilization alone does not prove congestion, and a low average does not rule it out. A growing queue, new discards, and higher latency in the same interval confirm a bottleneck. During a short burst, an interface may carry the same average bytes per second as yesterday while packets from an interactive application wait behind a large transfer.

Collect counters at both ends of the suspected segment: the client access port, switch uplink, WAN interface, virtual switch, and server interface. RFC 2863 defines the standard IF-MIB counters ifHCInOctets, ifHCOutOctets, ifInErrors, ifOutErrors, ifInDiscards, and ifOutDiscards. They work across vendors, but compare deltas and account for a device restart or counter reset.

Errors and discards mean different things. CRC and other input errors usually point toward the physical layer, cable, optics, transceiver, or parameter negotiation. Discards without physical errors usually indicate a full queue, a QoS policy, or insufficient buffering. Cisco documentation for show interfaces directly connects a rising Total output drops value to output queue saturation, although exact counter semantics vary by platform.

On a Windows server, collect built-in counters before morning. This command creates a circular log and samples network, TCP, processor, memory, and disks every 15 seconds:

logman create counter MorningTrace -o C:\PerfLogs\MorningTrace.blg -f bincirc -max 1024 -si 00:00:15 -c "\Network Interface(*)\*" "\TCPv4\Segments Retransmitted/sec" "\Processor Information(*)\% Processor Time" "\Memory\*" "\PhysicalDisk(*)\*"
logman start MorningTrace

Stop collection after the problem window:

logman stop MorningTrace

Microsoft recommends Data Collector Sets for long-running observation when a quick look at Task Manager misses the problem. Its network-counter guidance includes Bytes Sent/sec, Bytes Received/sec, Output Queue Length, errors, discards, and TCP Segments Retransmitted/sec. A threshold copied from someone else's article does not replace your baseline: compare like mornings and the actual interface capacity.

On Linux, sar provides a similar first view if sysstat already collects history:

sar -n DEV,EDEV,TCP,ETCP -s 07:30:00 -e 10:00:00

In DEV output, inspect rxkB/s and txkB/s; in EDEV, inspect rxerr/s, txerr/s, rxdrop/s, and txdrop/s; in ETCP, inspect retrseg/s. Field names can vary between versions, so save the header with the data.

Control pairs separate a slow server from the network

You distinguish the network from the server by comparing operations that share part of the path, not with a ping command. A stable ping to the server confirms only that small ICMP packets pass under those conditions. The application may be waiting for DNS, TLS, a web-server queue, a database lock, or a disk, and a network device may treat ICMP differently from production traffic.

Build control pairs. Access one application from a client in the problem segment and from a client close to the server. Then access another healthy server over the same path from the problem client. The result is a simple matrix:

• Slow to one server from every segment: inspect the server or its nearest connection.
• Slow to every server from one segment: inspect access, uplink, Wi-Fi, or the segment route.
• Slow only by name but fast by IP: inspect DNS and name-resolution order.
• TCP connects quickly but the first byte arrives late: inspect the application, database, disk, or server queue.
• Latency and loss rise toward several destinations: find a shared network segment.

On the target server, measure CPU, available memory, paging, disk latency, request queue length, and active connections in the same second. High utilization on the server's network interface still does not make the network guilty: the server may generate a backup flow itself or take a long time to serve requests because of its disk.

iperf3 is suitable for testing throughput between two controlled hosts. ESnet's documentation says that both client and server can emit JSON and that -P sets parallel streams. Begin with one short stream and test the directions separately:

iperf3 -c 10.20.0.15 -t 15 -J
iperf3 -c 10.20.0.15 -t 15 -R -J

Do not start many parallel streams on an already saturated production link: the test adds load and can worsen the incident. Approve the window, cap the test, or use an isolated VLAN. iperf3 answers a question about available throughput between two hosts, but it does not simulate the latency of a particular database or file operation.

A short packet capture helps when you need to see where waiting begins: whether SYN repeats, a TCP retransmission occurs, one side delays acknowledgments, or DNS takes too long. Capture both ends of one session with synchronized clocks. A client-side capture alone cannot always distinguish loss in transit from a server delay.

Wi-Fi and wired networks need different evidence

If Wi-Fi users complain, repeat the same operation over a cable in the same subnet or along the closest possible route. Morning changes the radio environment: clients wake together, access points gain associations, contention for airtime rises, and devices may roam between access points. The wired uplink can remain moderately loaded throughout.

For Wi-Fi, inspect client count per radio, airtime utilization, frame retries, signal level, signal-to-noise ratio, channel selection, and roaming events. Ethernet-port utilization on the access point does not show how long clients contend for the radio. Two clients with poor signal can consume a disproportionate share of airtime at low rates.

Do not draw a conclusion from the laptop's Wi-Fi bars. They estimate signal but do not show contention, interference, retries, or delay behind the access point. You need data from the controller or access point and a simultaneous wired control test.

If the cable is fast and radio is slow, check the distribution of clients across access points and bands before increasing power. Excessive power can keep a client attached to a distant access point and reduce channel reuse. If both cable and radio are slow, return to the shared uplink, WAN, or server.

Also rule out the morning arrival of guest and personal devices, automatic photo synchronization, and mobile operating-system updates. Traffic broken down by SSID and destination helps; guessing from the number of people in the office does not.

Two mornings establish causation

A stepwise diagnosis fits into two comparable mornings if you prepare collection in advance. Use the first morning to localize the fault and the second to test one controlled change. Do not change the backup schedule, QoS, and Wi-Fi configuration at the same time: even an improvement will not reveal what worked.

1. The day before, choose the exact user operation and control hosts. Synchronize time, enable circular collection on suspected interfaces and servers, and export job schedules.
2. On the first morning, mark the beginning and end of the symptom. Find the first resource where a queue, latency, or discards rise at the same time, and name the largest flows.
3. Check the dependencies of the suspected cause. For logon, these are DNS, the domain controller, GPO, and profile storage; for backup, the source, network, and repository; for an application, the web node, database, and disk.
4. Choose one reversible change: move the job, cap its bandwidth, reduce concurrency, or direct a test group of clients to another resource.
5. Repeat the same measurements on the second morning. The theory holds if the suspected factor changes, the corresponding queue disappears, and the user operation becomes faster.

Consider a typical reasoning failure. At 08:10, users complain about file access and the WAN graph reads 95 percent. The team immediately buys a wider link. Complaints remain after the upgrade: the backup did fill the WAN, but the files were on local storage where the same read process raised disk latency. A control pair using a client close to the server would have shown slow opening without the WAN and avoided the link replacement.

Another case looks opposite. The server has low CPU and normal disk latency, but clients at several sites slow down together. ifOutDiscards rise on the central outbound interface, and limiting morning update distribution removes both the discards and the delay. The network was the bottleneck in this case, and the schedule change confirmed the mechanism.

Keep the evidence package together: graphs with the same time axis, counter deltas, job logs, control-operation results, and a list of changes. Its purpose is not a polished report. It keeps you from investigating the same incident again next month after another schedule changes.

A fix must remove the queue, not the graph

Choose the fix for the mechanism you found. Treat logon storms by reducing and spreading logon operations, placing needed content locally, fixing DNS and profiles, and sometimes adding capacity to a specific service. Treat background transfer with scheduling, bandwidth limits, and concurrency limits. A saturated uplink calls for flow redistribution, correct QoS, or added capacity after checking both ends of the ports.

QoS does not create bandwidth. It protects latency-sensitive traffic during congestion when classes match real applications and the policy sits on the actual constrained interface. Blindly prioritizing "all corporate traffic" only moves loss into another class. After a change, check every class queue and user-visible latency.

A link upgrade is justified when useful load consistently approaches available speed, output queues and discards rise, physical errors are absent, and moving or limiting background flows does not meet business requirements. If the interface is free while the queue grows on a server disk, a new link will fix nothing.

After repair, keep light continuous monitoring: duration of the synthetic operation, utilization of important interfaces, deltas for errors and discards, TCP retransmits, server disk latency, and actual heavy-job windows. Set thresholds from your baseline and add a duration condition so an acceptable one-second spike does not wake the on-call engineer while a ten-minute degradation does not vanish into an hourly average.

For complex infrastructure, GSE.kz can design the server and network portions as one system and support it around the clock across Kazakhstan. Even an integrator starts with a timeline and measurements, because buying equipment without them remains a bet.

Close the investigation with a testable statement: "From 08:02 to 08:27, job X transferred data through interface Y, outbound discards rose there, and after limiting it to the approved rate, operation Z returned to baseline latency." If you cannot write that sentence, you have not found the cause.