Think time in load testing: what it is and how to set it

Think time in load testing is the pause a virtual user takes between two actions, standing in for the seconds a real person spends reading a page or filling in a form. It decides how hard each virtual user pushes: the longer the pause, the fewer requests per second the same number of users sends. Measure it from real-user data, randomise it around that value, and write it into the script with your tool’s own pause command.

This is arithmetic with no test behind it: one request per loop, a 0.5-second response, and users divided by (response time + think time).

What is think time in load testing?

Think time is the deliberate wait a test script inserts between the steps of a user journey. It models the human part of a session: reading, comparing, typing.

In a shop script it sits between “open the product page” and “add to cart”, outside any request. LoadFocus’s guide to delays in load testing separates it from a ramp-up delay, which adds users gradually, and a startup delay between users starting, and notes that many tools use the bare word “delay” for the ramp-up kind. When a tool offers a “delay” field, check which one it means.

Why does think time change the load from the same number of users?

With a fixed number of virtual users, each one waits for a response, pauses, and only then sends the next request. Its loop takes response time plus think time, so every added second of think time lowers the requests each user sends per second.

One hundred users with no pause send 200 requests per second against a 0.5-second response; with a 5-second pause they send about 18, so two runs “at 100 users” can be very different tests. The k6 documentation describes the same effect for its closed model: the next iteration starts only when the previous one finishes, so slower responses also lower the rate (checked on 9 October 2026).

Cutting think time to get more load from fewer users has a cost: twenty users with no pauses can match the request rate of several hundred who pause, while holding far fewer sessions and connections open than production would.

What is the difference between think time and pacing?

Think time is a pause after a step, so a loop gets longer whenever responses slow down. Pacing fixes the time from the start of one loop to the start of the next, and shortens the wait when the work took longer.

With 30 seconds of pacing, a user starts a loop every 30 seconds whether its requests took 2 seconds or 20, which suits a test built from business volumes such as “500 orders an hour”. The docs for Locust’s constant_pacing spell out the edge case: if the task runs longer than the interval, the wait drops to zero (checked on 9 October 2026). Many scripts use both, with think time between steps and pacing on the whole loop.

Should think time be fixed or random?

Random, around an average you measured. A fixed pause keeps users that started together in step, so they hit the same page at the same moment, loop after loop.

Those synchronised waves can create spikes production never sees, and a random pause spreads users out. Keep the average where your data puts it: a uniform pause between 2 and 8 seconds averages 5, the same mean load as a fixed 5-second pause. Uniform is the simple default; a normal (Gaussian) shape clusters pauses around a typical value, and an exponential one gives many short waits and a few long ones.

How do you choose think time values?

Take them from what real users do on each step, using web analytics, access logs or real-user monitoring. Use a separate value per step, because reading a product page takes longer than pressing a button.

Time on page in analytics, or the gap between consecutive requests of one session in access logs, is close to the think time for that step. Use the median as the average pause and the spread to set the random range, and drop idle gaps such as a tab left open over lunch.

An API called by other programs has no human in the loop, so model its request rate directly. Without data, write your assumed values into the test plan so a later run can replace them; the step-by-step guide to running a load test shows where they fit.

How do you add think time in k6, JMeter, Gatling, Locust and Artillery?

Each tool has its own pause command, and most also have a pacing or rate option.

The table above and the notes below come from each project’s documentation, checked on 9 October 2026; all five tools appear in our review of open source load testing tools.

k6. sleep(t) pauses the virtual user for t seconds; the docs build random pauses with Math.random() or randomIntBetween() from k6-utils:

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // 2 to 8 seconds
  http.get("https://example.com/cart");
}

JMeter. Among the timers, Constant Timer takes a delay in milliseconds, the Uniform and Gaussian Random Timers add a random part to a fixed offset, and Constant Throughput Timer varies its pauses to hold a target of samples per minute. A timer runs before each sampler in its scope, so one timer at thread group level pauses before every request.

Gatling. pause(2, 8) waits a uniform random time, and pace(30) in a loop runs it at most once every 30 seconds. At simulation level you can switch all pauses to a normal or exponential distribution, or turn them off with disablePauses().

Locust. wait_time runs after each task, so a task with two requests under constant_throughput(2) sends four requests per second per user.

Artillery. A think step pauses for a number of seconds, and a think.jitter setting under config.http.defaults adds random variance to every think step. For two of these tools side by side, see k6 vs Artillery.

Does think time matter in an arrival-rate test?

Less, as far as the request rate goes. When the tool starts new iterations at a set rate, pauses decide how long each user stays and so how many are active at once.

k6’s arrival-rate executors pace iterations through their rate setting, and the docs advise against a sleep at the end of the iteration; Artillery’s load phases likewise create a set number of new virtual users per second (both checked on 9 October 2026). Think time between steps still shapes each session.

How do LoadFocus’s script tools set think time?

They write it into the k6 or JMeter script as a starting value for you to adjust.

The import from cURL, HAR, Postman or OpenAPI turns a captured request into a k6 script that ends each iteration with sleep(1); treat that second as a placeholder for your measured values. LoadFocus’s AI test generator is instructed to give every step a think time, writes it as sleep() for k6 or a Constant Timer for JMeter, and warns when a multi-step scenario has none.

FAQ

Can you run a load test with zero think time? Yes, to find the maximum throughput of an endpoint or for a stress test, if you report the result as requests per second. It says little about how many real users the system can serve.

Does think time count in response times? Not in request timings. In k6, http_req_duration covers sending, waiting and receiving, while iteration_duration covers the whole loop (metrics reference, checked on 9 October 2026). A JMeter Transaction Controller leaves timers out of its time unless you tick the option that includes them.

Related reading

• Open vs closed workload model: which one should you use?
• Little’s law in load testing: size and check your tests
• How to run a load test: a step-by-step guide
• Queueing theory: what it is and why latency spikes

The technical claims in this article have not been independently reviewed.