A JMeter Open Model Thread Group run ends with failed, cut-short samples. What in the schedule causes that?

## What actually ends the run An Open Model Thread Group runs a starter task alongside the workload. The starter walks the schedule, sleeps until each scheduled arrival instant and submits a thread for it. When the generator has no events left, the starter computes how much of the schedule's total duration remains, sleeps out that remainder, and then shuts everything down. Shutdown is not polite. The manual puts it plainly: the thread group terminates threads as soon as the schedule ends — the threads are interrupted after all arrivals and pause intervals. Each surviving thread is asked to stop, then interrupted, and its task cancelled. A sampler that implements `Interruptible` has its in-flight work cancelled at that point, which is why the last samples of the run are failures with truncated durations rather than the successes you would get if they had been left alone. ## The log tells you this happened The thread group logs both outcomes. When nothing is left running it says it will shut the pool down. When threads are still live it prints the count and the remedy: > Test schedule finished, however, there are 37 thread(s) still running. Will interrupt the threads. If you want to keep some time for the threads to complete, consider adding pause(10 min) at the end of the schedule. So the first diagnostic step for a tail of failed samples is not the result file at all — it is `jmeter.log`. If that line is present, the failures are the harness cutting its own run short, not the system under test misbehaving. Reading the failures as a real defect is the classic misdiagnosis here. ## Why a trailing pause is the fix A pause step occupies duration without scheduling arrivals, and it is honoured in full even when nothing is left to do. Adding one at the end therefore extends the moment at which the starter gives up, and every thread that finishes inside that window completes normally. A hold-then-pause profile with headroom looks like this: - `rate(50/sec) random_arrivals(10 min)` — the load you actually wanted, - `pause(2 min)` — a deliberate quiet stretch inside the profile, - `random_arrivals(10 min)` — the same fifty per second again, - `pause(5 min)` — headroom, so the arrivals issued at minute twenty-two are not cut off. Note which steps do **not** buy you time: 1. A trailing `rate(0)` adds nothing — a rate step is a level and occupies no duration at all. 2. Setting Random Seed changes where arrivals fall inside a span, never how long the schedule lasts. 3. Lengthening the last `random_arrivals` span does extend the run, but it also keeps generating load, which is not what you asked for. ## Sizing the trailing pause The pause has to cover the slowest iteration that can still be in flight when the last arrival is issued, so the input is your own observed iteration duration from a previous run, not a round number. Two practical habits: - Keep the pause in the schedule text rather than in a comment or a wiki page, so it travels with the plan. - Re-check it after adding steps to the iteration; a plan whose iteration grew from two seconds to thirty will start truncating again with the old pause. ## What this is not This behaviour belongs to the Open Model Thread Group specifically — it is a property of *this* element's starter, not something you configure with an error action or a scheduler checkbox. There is no field on the element to soften it, and `bin/jmeter.properties` carries no key naming this thread group at all; the schedule text is the only lever. That is also why the truncated tail is so easy to misread: nothing in the GUI warns you, and the only signal outside the log is a cluster of failures whose durations stop dead at the same instant.