Action cancellation

Stop signal task with an SSRT estimate you can check

Answer which way each arrow points, and on a quarter of the trials a white bar drops across it shortly afterwards and you have to cancel the keypress you had already started — 128 trials in about four minutes, free, with nothing withheld at the end. The delay before the bar is tracked by a staircase until you are failing about half the stop trials, which is the one condition under which stopping latency can be estimated at all. The number that comes out is called SSRT, it is never observed, and this page prints every input that produced it.

100% free
No signup
128 trials, 32 with a stop signal
50 ms staircase
SSRT with its three inputs

128 arrows, about four minutes with two breaks. Answer the side each one points as fast as you can; on 32 of them a white bar drops across the arrow shortly after it appears, and on those you must not finish the keypress you had already begun. The bar comes late enough that you will fail roughly half of them — that is the design working, not you failing.

The procedure, in full

Go task: an arrow pointing left or right, half of each, drawn in one pale gray
Keys: F for left and J for right, read by physical position so the layout does not matter
Stop signal: a white frame and a white bar across the arrow on 32 of the 128 trials — luminance and shape, no hue
Delay: starts at 200 ms and moves 50 ms after every stop trial: later when you stop, earlier when you do not
Window: 1250 ms from the arrow appearing, then the trial closes
Void: answered inside 150 ms, answered before the arrow appeared, or interrupted by this tab losing its frames
Order: runs of the same trial type capped at 6 and runs of the same side at 4

Do not hold back for the bar. Waiting makes stopping easy, the delay lengthens to compensate, and the estimate ends up describing a strategy instead of a brake — so the run checks afterwards whether your speed drifted and reports what it found.

The practice trials hold the bar at a fixed 200 ms and say what happened after each one. They feed nothing: the tracked delay begins at 200 ms when the scored run does.

How to run the stop signal task

Answer fast, cancel when the bar drops, and do not try to be clever about it.

Rest two index fingers on F and J
F answers an arrow pointing left, J one pointing right, and the keys are read by physical position so the same two keys work on a QWERTY, an AZERTY or a Dvorak layout. Two on-screen buttons take a tap instead where there is no keyboard, and the result says how many of your answers came that way, because an arm that has to arrive somewhere is not the resting finger this task is built around.
Meet the bar on 16 practice trials at a fixed delay
Practice holds the stop signal at a flat 200 ms and tells you after each trial what happened, so the bar is familiar before it starts moving. The scored run then resets the delay to 200 ms and begins tracking: every stop you make pushes the next delay 50 ms later, every one you miss pulls it 50 ms earlier.
Answer at your normal speed and do not wait for the bar
This is the one instruction that decides whether the run produces anything. Slowing down makes stopping easy, the staircase answers by lengthening the delay, and the estimate ends up describing your patience rather than your brake. Two breaks come after trial 44 and trial 88. At the end you get the SSRT, the staircase plotted trial by trial, the delay the display actually produced against the delay that was asked for, and three checks on whether the model behind the estimate held.

Technical specifications

Trials	128 scored — 96 go trials and 32 stop trials, a 25% stop share — plus 16 optional practice trials at a fixed delay that feed neither the staircase nor any figure. Breaks after trial 44 and trial 88
Go task	A two-choice arrow, left or right, 64 of each, in one pale gray. Two choices rather than one because a stop signal has to interrupt a decision that is already running, and a single-key task gives it nothing to interrupt
Stop signal	A white frame around the panel and a white bar across the arrow, drawn inside the same graphic so it costs one repaint and no layout pass. Luminance and shape carry it, never color: a signal that a red-green deficiency could miss would be scored as a failure to inhibit
Delay tracking	1-up/1-down in 50 ms steps from a 200 ms start, floored at 0 and capped at 800 ms. Equal steps with that rule settle where you succeed half the time, which is the point the integration estimator is defined at and the reason no other rule is offered
SSRT method	Integration. Every go trial that produced a key is ranked, choice errors included, with one copy of the slowest time entered for each go trial that produced none; the time at the rank matching your response rate on stop trials has the mean delay subtracted from it
Realized delay	The bar is drawn on the first frame at or after the requested delay and that paint is timestamped, so the delay used in the arithmetic is the one that happened. On a 60 Hz panel it runs about a frame later than requested, and the run reports the median offset it measured
Response window	1,250 ms from the arrow appearing. A trial answered inside 150 ms, answered before the arrow painted, or interrupted by this tab losing its frames is void — it does not move the staircase and it is requeued at the end
What leaves the page	Nothing unless you press copy, which puts plain text on your own clipboard: the estimate, its three inputs, the staircase convergence, the assumption checks and the run seed

Frequently asked questions

Why does the stopping time have to be estimated instead of measured?

Because a successful stop produces nothing to time. On every other timed task the thing being measured ends in a keypress with a timestamp on it, but here success is the absence of a response, so the stopping process leaves no trace of when it finished. What can be observed is the proportion of trials where the response escaped at a given delay, and that proportion is informative: the later the signal comes, the more often going wins. The estimate reads the stopping latency out of that relationship, which is why it needs a model and why the model's assumptions are printed alongside the number.

What is the horse race the estimate is built on?

Going and stopping are treated as two independent processes started at different times, and whichever finishes first decides the trial. The go process starts when the arrow appears; the stop process starts when the bar appears, one stop-signal delay later. If going finishes first you press, and if stopping finishes first you do not. That single idea gives the whole estimator: at the delay where you press exactly half the time, the finishing time of the stopping process must line up with the point in your own go-time distribution that half your responses fall below. Subtract the delay from that time and what is left is how long stopping took.

The delay you report is not the delay you asked for. Which is right?

The reported one, and the gap between them is the display rather than a rounding error. A browser paints on a schedule — about every 16.7 ms on a 60 Hz panel — so a bar scheduled for 250 ms after the arrow cannot appear at 250 ms; it appears on the first frame at or after it. This page timestamps that paint, uses the measured delay in the subtraction, and prints the median offset it found. On the failed stop trials where your key landed before the bar was even due, no bar was drawn at all and the requested delay plus that measured offset is used instead, which the results panel says out loud rather than folding in quietly.

Can I not just wait for the bar and stop every time?

You can, and it destroys the estimate rather than improving it. Holding back lengthens your go times, which makes stopping easy, which makes the staircase push the delay later, which makes stopping easy again — the loop is stable and the number that comes out the far end describes a strategy. The run therefore checks for it two ways: it compares your go speed in the first quarter of the trials with the last quarter, and it checks that the responses which escaped the bar were faster than your go trials generally, which is what the race model requires and what waiting breaks. Both results are printed whether they pass or not.

Why is the stop signal something you see rather than something you hear?

Because a sound this page cannot verify you heard would be recorded as a failure to inhibit, which is the worst possible way to be wrong here. Audio versions are common in the laboratory, where the volume is set by the experimenter and the headphones are known; in a browser the volume is unknown, the output may be a laptop speaker in a noisy room, and a missed tone and a failed brake produce exactly the same data. A visual bar drawn over the arrow is on the same screen you are already watching, and its onset can be timestamped to the frame.

My estimate came out very low, or very high. What went wrong?

Look at the three checks under it before reading the number at all. An estimate near or below 100 ms usually means the response rate on stop trials drifted far from half, so the delay was not sitting where the estimator assumes; one above 400 ms usually means go times crept up across the run, which is the signature of waiting. A negative estimate is arithmetically possible and physically meaningless, and it happens when the mean delay ends up longer than the go time at the matching rank. All three are reported as failures of the run rather than as facts about you, and the fix in each case is a second run at your natural speed.

Why does the go task use two keys when the neighboring task uses one?

Because there has to be a decision in flight for the signal to interrupt. A single-key task gives you a response to withhold, which is a different operation: the hand never commits, so nothing needs cancelling. Two choices force the go process to select as well as execute, and it is that running selection the bar has to catch. The consequence shows up in the numbers — a run here produces a latency in milliseconds, while a one-key task can only ever produce a count of failures.

The horse race, the staircase, and the four ways this estimate goes wrong

The stop signal task exists to measure one thing a go/no-go cannot: how long it takes to cancel an action that is already running. The distinction is not a quibble. The go/no-go test replaces the go stimulus with a different one, so the response is never started and the only quantity available is a count of the times it was started anyway. Here the arrow comes first and the bar comes later, so the response is genuinely under way when the instruction to abandon it arrives — and because the delay between the two can be moved, the point at which going and stopping are evenly matched can be found. That point is what makes a latency estimable. Logan & Cowan (1984), On the ability to inhibit thought and action: A theory of an act of control, Psychological Review is where the model comes from: two independent processes racing, the winner deciding the trial, and nothing else in it.

The staircase is not a convenience; it is a precondition. The integration estimator reads the stopping latency out of your own go-time distribution at the rank matching your response rate on stop trials, and that reading is only stable when the rate sits near half — a delay so short that you stop every time, or so long that you never do, carries almost no information about where the crossover is. So the delay moves 50 ms later after every success and 50 ms earlier after every failure, which is a rule that converges on 50% by construction rather than by tuning. The page plots the whole walk, prints how many turnarounds it produced and the spread of the ones it averaged, and says whether the delay spent trials pinned against the ends of its range, because a staircase that never settled makes every figure downstream of it decorative. 150-250 ms is the span published estimates fall in, per Verbruggen et al. (2019), A consensus guide to capturing the ability to inhibit actions and impulsive behaviors in the stop-signal task, eLife — a span across studies rather than a distribution, so your figure is placed next to it and never converted into a rank against it.

Four things break this estimate, and three of them are checked on the page. The first is strategic slowing, where you answer more slowly than you naturally would in order to catch the bar; the run compares your go speed across quarters and reports the drift. The second is a violated race: the responses that escape the bar must be your quicker ones, and if the mean time on failed stops comes out above your ordinary go time then going and stopping were not independent and the arithmetic does not apply. The third is a drifted rate, reported with a Wilson interval so you can see whether half is even inside it. The fourth is the one nothing on this page can fix — a run of 32 stop trials is a good deal shorter than the consensus guide asks for, and the spread of the staircase reversals beside the estimate is the honest way to see what that cost. If you want the same executive machinery measured through conflict rather than cancellation, the Stroop test and the flanker task are the neighbors; through rule-switching, the Wisconsin card sorting test and the trail making test; through sustained clerical speed, the digit symbol substitution test. Risk-taking under reward, which is impulsivity of a different kind entirely, is the balloon analogue risk task.

A reaction time here is the interval between the frame that painted the stimulus and the timestamp the browser attached to your key, both read from the same monotonic clock. What neither can see is the display pipeline behind it, so on a 60 Hz screen roughly 16 ms of every figure below is the machine rather than you. That is the timing floor: two numbers closer together than that are the same number, and this page reports no precision it cannot support.

This is a measurement exercise, not a clinical assessment. It reports what you did on this page against a stated reference and nothing more — it cannot establish ADHD, an impulse-control disorder or any other clinical condition. Only a qualified professional, working with more than a browser, can make that judgment.

Where the estimate is worked out

Every number on this page is worked out by JavaScript running in the tab you are reading it in. Your answers, your reaction times and your score are never uploaded, logged or kept — which is also why the test carries on working after you disconnect from the network, and why nothing here can be held back behind an email address.

The staircase, the go-time distribution and the estimate are all built and thrown away inside this tab. Nothing about a run is transmitted at any point, including the seed that reproduces it — if you want that run back, the copy button is the only way to keep it, and reloading the page loses it.