skip to content

What does Playwright's slowMo launch option do, and why does it not make a flaky test reliable?

level: middleimportance: should knowfreq 44%

answer

  1. Measured in milliseconds, set at launch
  2. Spacing changes, behaviour does not
  3. Every operation pays the price
  4. Extra time is not a readiness signal
  5. A flashlight, not a patch

basics

~10 s

slowMo is a launch option that pauses Playwright by the given number of milliseconds between operations so a human can follow the run. It hides races behind extra delay; it never removes them.

solid answer

~40 s

`slowMo` is a number of milliseconds passed to `browserType.launch()` or `launchPersistentContext()`. Playwright waits that long between operations, so clicks and fills happen at a pace you can watch. It is a debugging aid, and it is the natural companion to `headless: false`. It does not touch auto-waiting or actionability - a click still waits for the element to be visible, stable and enabled either way. That is exactly why it is not a flakiness fix: the extra delay gives a slow backend more time to finish, so a test that races the hotel-booking search results starts passing without the race going away. Committing `slowMo` to a shared run trades an honest failure for a slower suite that still fails on a bad day, and it inflates every test's wall-clock time against its timeout budget.

code

typescript · 7 lines
typescript
import { chromium } from '@playwright/test';

const browser = await chromium.launch({ headless: false, slowMo: 250 });
const page = await browser.newPage();
await page.goto('https://staging.example.com/hotels/search');
await page.getByRole('button', { name: 'Search rooms' }).click();
await browser.close();

go deeper

for a junior

Know that the value is milliseconds, that it is set in the launch options, and that its purpose is letting a person watch a run rather than making anything more reliable.

for a middle

Explain that the pause applies per operation and per browser, that auto-waiting is untouched, and why extra delay masks a race instead of removing it.

for a senior

Show that you treat a slowMo-only pass as a diagnosis: name the operation that fires too early and replace it with a wait on the state the test depends on.

for a principal

Own the standard that timing hacks never enter shared configuration, and make sure the suite has a cheaper way to reproduce a race than slowing every test down.

`slowMo` is one of the options on `browserType.launch()` and `browserType.launchPersistentContext()`. Its value is a number of milliseconds, and Playwright pauses by that much between operations it sends to the browser. `chromium.launch({ headless: false, slowMo: 250 })` turns a run that finishes in a blur into a sequence you can actually follow. ## What it does mechanically - The delay is applied **per operation**, not once per test. A test doing forty locator calls at `slowMo: 250` gains roughly ten seconds of pure waiting. - It is a **launch-time** setting, so it applies to every context and page created from that browser. There is no way to slow only one step. - It changes nothing about *what* Playwright does - the same actions, the same order, the same automation protocol. Only the spacing changes. - It is unrelated to how long Playwright waits *for* the page. Actionability checks and auto-waiting run exactly as before. ## Why it looks like a flakiness fix A flaky test usually contains a hidden race: the test acts at a moment the application has not finished preparing. On a fast machine the test wins the race and fails; on a slow one it loses and passes. `slowMo` puts a fixed pause in front of every operation, so the application gets extra time it was never asked for. | Approach | What it changes | What it proves | |---|---|---| | `slowMo: 500` | Adds a fixed pause before every operation | Nothing - the race still exists | | Waiting on a readiness signal | Blocks until the app is actually ready | The condition the test depends on | | Raising a timeout | Allows a slower app to finish | Only that the app is slow, not that it is correct | The middle row is the fix. The other two buy silence. ## The costs of leaving it on 1. **Wall-clock time.** Every operation in every test pays the delay, and the total grows with the size of the suite, not with the difficulty of the flake. 2. **Timeout pressure.** A test that took eight seconds may now take twenty-five, so tests start failing on their time budget for a reason that has nothing to do with the application. 3. **Lost signal.** The race is still in the code. It resurfaces on a loaded CI machine, in a different browser, or after someone shaves the delay back down. 4. **Misleading review.** A reviewer reading `slowMo: 300` in shared launch options learns nothing about which step was unstable or why. ## When slowMo genuinely earns its place - You are watching a hotel-booking flow headed, trying to see which of six room cards the click actually lands on. - You are demonstrating a reproduction to someone else and want the steps legible. - You are recording a short walkthrough of an existing flow rather than measuring it. In all three the value is human perception, and the run is throwaway. That is the register `slowMo` belongs in. ## Diagnosing rather than sedating When a test only passes with `slowMo`, treat that as a **finding**, not a solution. Turn the option off and ask which operation now happens too early: - Is the test acting on a locator that exists in the DOM before the data behind it arrives? - Is it asserting on a value that is rendered once and then replaced by a second render? - Is it clicking a control that is visible but still disabled while the guest profile loads? Each of those has a targeted answer - a web-first assertion, a wait on the state the test actually depends on, or a test that stops reaching for the element until the condition holds. Any of them removes the flake permanently, keeps the suite fast, and leaves a diff that explains itself. `slowMo` is the flashlight you use to find the problem, never the patch you ship for it.

  • If slowMo is not the answer, what do you actually change in a test that races the hotel search results?
    Make the test wait on the condition it depends on rather than on the clock: assert with a web-first matcher that the results list shows the expected room, or wait for the control to be enabled before clicking. The wait then ends as soon as the app is ready, so the test is both stable and fast.
  • Does slowMo affect Playwright's timeouts in any way?
    Not directly - it does not lengthen any timeout. But because it adds real elapsed time to every operation, a test near its budget can start timing out once slowMo is on. The delay competes with the budget rather than extending it.

saying these in an interview costs you the question

  • Says slowMo increases Playwright's timeouts
  • Commits slowMo to shared options to stop flakes
  • Thinks slowMo replaces waiting on a readiness condition
  • Believes slowMo delays only navigation, not actions
  • Assumes slowMo is free because tests still pass