Timing is the lever that decides whether an Nmap scan finishes before your coffee gets cold or runs so slowly it slips under an intrusion-detection sensor. When you are sweeping a /16 for an asset inventory, you want every packet Nmap can safely push. When you are validating a firewall rule on a production segment that feeds a SIEM, you want the opposite: a trickle of probes that never trips a rate-based alert. Same tool, same target, wildly different behavior - and the difference is almost entirely down to how you tune timing. This guide is part of the complete Nmap guide, and it focuses on the two knobs that matter most in the field: the six timing templates (-T0 through -T5) and the fine-grained rate and retry controls underneath them.
Why timing matters for network engineers
There are two directions you can push a scan, and they pull against each other. The first is speed: cover a large address range or a big port set in as little wall-clock time as possible. If you are auditing your own data-center VLANs on a reliable, low-latency network, there is no reason to wait - fast is correct. The second is stealth, or more precisely, staying under a rate threshold. Every IDS/IPS worth its license watches for a host firing connection attempts at many destinations or ports per second. Slow the probes down enough and the scan disappears into the noise floor of normal traffic. That is the same reasoning behind the deliberate techniques in Nmap firewall and IDS evasion, and timing is the cheapest evasion control you have because it is a single flag.
The honest tradeoff is time. Going slow to dodge a sensor can turn a one-second scan into a forty-second one, as you will see below with real captures. So the practical question is never "fast or slow" in the abstract; it is "what is the fastest I can go without tripping the thing watching this segment." The templates give you six pre-tuned answers to that question.
The six timing templates: -T0 to -T5
Nmap ships six timing templates. Each one sets a bundle of underlying parameters (probe delays, parallelism, retries, timeouts) to sensible values for a given intent, so you rarely need to touch the individual knobs. -T3 is the default and is what runs when you pass no timing flag at all. Everything below -T3 trades speed for stealth; everything above trades caution for speed.
The pattern is worth internalizing. -T0 and -T1 exist to defeat detection: they serialize probes (one at a time, never in parallel) and insert long fixed delays between them, so the packet rate never spikes. -T4 and -T5 do the reverse, firing many probes concurrently and giving up on slow responses quickly. -T2 and -T3 sit in the middle, with -T2 the polite choice when you care about the target's load or a sensor's patience.
The proof: T4 versus T2 on the same scan
Templates are easy to describe and easy to underestimate. So here is the same scan run twice against the same host in the PingLabz Nmap Recon Lab (a Cisco router at 10.10.10.1, Nmap 7.95), changing nothing but the timing template. The scan is a fast top-100-port sweep (-F).
First, aggressive:
$ nmap -T4 -F 10.10.10.1
... 22/tcp open ssh ; 23/tcp open telnet ...
Nmap done: 1 IP address (1 host up) scanned in 1.37 secondsNow the identical scan, polite:
$ nmap -T2 -F 10.10.10.1
Nmap scan report for 10.10.10.1
Host is up (0.0033s latency).
Not shown: 98 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 40.67 secondsSame host, same 100 ports, same results (SSH and Telnet open, 98 closed). The only difference is the clock: 1.37 seconds at -T4 versus 40.67 seconds at -T2, a factor of roughly thirty. That thirty-fold penalty is not waste - it is the whole point. The -T2 run spreads its probes out far enough that the per-second rate stays low, which is exactly what keeps it under an IDS rate threshold. On a lab segment with nothing watching, that patience buys you nothing and you would obviously reach for -T4. On a production edge behind a tuned IPS, that patience is the difference between a clean audit and a page to the SOC.
Fast on a reliable network
To show the other side, here is -T4 doing what it does best - a wider port range against a real internet host, scanme.nmap.org, captured from a Debian VM. The --reason flag (covered more in Nmap port scanning) makes Nmap print why it assigned each state.
$ nmap -T4 --reason -p1-150 scanme.nmap.org
Starting Nmap 7.95 ( https://nmap.org ) at 2026-07-05 15:06 PDT
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up, received reset ttl 50 (0.018s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 143 closed tcp ports (reset)
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 50
80/tcp open http syn-ack ttl 49
135/tcp filtered msrpc no-response
136/tcp filtered profile no-response
137/tcp filtered netbios-ns no-response
138/tcp filtered netbios-dgm no-response
139/tcp filtered netbios-ssn no-response
Nmap done: 1 IP address (1 host up) scanned in 1.52 seconds150 ports across the public internet in 1.52 seconds. Note the Not shown: 143 closed tcp ports (reset) line: those hosts answered with a RST, so Nmap is confident they are closed (the host actively refused), not filtered. The five no-response ports (135-139) are filtered - something dropped the probe silently, most likely a firewall. Over a well-behaved link, -T4 gathers all of that almost instantly. Push that same scan to -T5 on a lossy or high-latency path and you would start seeing ports mislabeled, because the insane template gives up on slow replies before they arrive.
Fine-grained timing controls
The templates are bundles of lower-level settings, and any of those settings can be overridden on the command line. You reach for these when a template is close but not quite right - for example, you want -T4's parallelism but with a hard cap on packet rate so you do not saturate a slow WAN link. Override flags always win over the template, so -T4 --max-rate 100 is perfectly valid.
A few of these deserve field notes. --max-rate is the single most useful control when you have an actual number to hit - if you know the IPS on a segment alerts above 50 connections per second, --max-rate 40 gives you a hard guarantee no template can. --host-timeout saves large sweeps: without it, one firewalled host that answers nothing can hold up the whole run while Nmap patiently retries. And --scan-delay is the honest, tunable version of the -T0/-T1 stealth behavior - if you need a specific inter-probe gap rather than the template's fixed values, set it directly.
Port count is the biggest lever
Before you spend an afternoon tuning parallelism, understand this: for most scans, the number of ports you scan dominates the runtime far more than the timing template does. Nmap's default is the top 1,000 ports per host. A full -p- scan hits all 65,535, which is 65 times the work. The -F (fast) flag drops you to the top 100, and an explicit list like -p 22,80,443 is faster still. The compact -F runs above finished in a second or two precisely because they scanned 100 ports, not 65,535.
So the first question for a slow scan is rarely "should I bump to -T5"; it is "do I actually need every port." If you are verifying that a firewall permits SSH and HTTP, scan those two ports and nothing else. Choosing the right port set is covered in depth in Nmap port scanning, and it will save you more time than any timing flag. Once the port set is right, then tune timing to fit the network.
When to choose T2 versus T4 in practice
For day-to-day network engineering the choice usually collapses to two templates. Reach for -T4 when you are on a reliable, low-latency network you control - a lab, a data-center VLAN, a wired LAN - and you want results now. It is the sane fast default for asset inventories and big internal sweeps, and the -T4 captures above show it losing no accuracy on a clean path. Reach for -T2 when the target segment is monitored and you must not trip a rate-based alert, or when you are scanning across a fragile or bandwidth-constrained link where hammering the target would cause collateral damage. The forty-second -T2 run earlier is the price of staying quiet, and on a production edge it is a price worth paying.
-T0 and -T1 are specialist tools for genuine detection evasion, and -T5 is for the rare case where you have a pristine link and are willing to trade a little accuracy for raw speed. Most engineers live between -T2 and -T4 and are right to.
Key takeaways
Timing in Nmap is a deliberate tradeoff between wall-clock speed and staying under a detection threshold, and the six templates (-T0 paranoid through -T5 insane) give you pre-tuned answers with -T3 as the default. The real proof is in the captures: the same top-100 scan of 10.10.10.1 ran 1.37 seconds at -T4 and 40.67 seconds at -T2, identical results, thirty times the patience - and that patience is what keeps a scan under an IDS rate threshold. When a template is close but not exact, override the underlying controls (--max-rate, --host-timeout, --scan-delay, parallelism, host-group size) to fit the specific link. Above all, remember that the port count you choose is a bigger lever on runtime than any timing flag, so scan only the ports you need first, then tune. Use -T4 for labs and reliable internal sweeps, -T2 for anything monitored or fragile, and pair this with deliberate firewall and IDS evasion techniques when the goal is stealth. For the full picture of how timing fits alongside discovery, scanning, and detection, work through the complete Nmap guide.
