playwright+timeout+waiting+for+the+safe+links+detonation+page+to

Not specified by the original author.

TL;DR

Detonation pages are slow by nature: the scan runs a browser farm behind the page, and rendering completion is not the verdict. A fixed Playwright timeout tuned for normal pages will always lose. Wait for a specific verdict element or status text with a generous, explicit timeout, poll the status rather than holding one navigation, and treat a still-running scan as a state to re-check later, not as a failure of the run.

playwright timeout waiting for the safe-links detonation page to render; the triage agent's browser step failed

Use this when

• The browser step fails with a timeout waiting for the detonation page.
• Manual visits to the same page eventually show a verdict.

Not for this skill when

• The page errors immediately with a block or not-found. That is a verdict or link problem, not slowness.
• The scan was never submitted, so no verdict will ever render. Check the submission step.

Steps

1. Time the page manually from load to verdict for several sample links. Verify: the real verdict latency range is measured.
2. Change the wait condition to a specific verdict element or status string, with a timeout above the measured worst case. Verify: the step waits on state, not on load events.
3. If the verdict is still pending at the limit, record the item as pending with its reference and continue the batch, scheduling a later status check. Verify: one slow link no longer fails the whole triage run.
4. Reduce repeat cost by caching verdicts per URL for the run, since campaigns reuse links across hundreds of messages. Verify: duplicate links do not trigger duplicate waits.
5. Run the step against a batch including a known slow link. Verify: all items end as verdict, cached or pending-scheduled, with no raw timeout failures.

Variant phrasings

playwright timeout waiting verdict page detonation

The verdict wait variant.

safe links detonation slow scan pending handling agent

The pending handling variant.

Compatibility: Playwright waiting strategies against Defender Safe Links status pages and sandbox result portals.

Why it happens

A detonation verdict is an asynchronous job wearing a web page as a costume. Automation written for synchronous pages, load then assert, mismatches the job model and times out on exactly the suspicious links that scan slowest.

Edge cases / pitfalls

• Suspicious pages scan slowest because the farm explores them longer. Timeouts therefore correlate with the items you most need verdicts for.
• Poll with increasing intervals to avoid hammering the status page during long scans.
• Log the final status text for every item; it is the evidence the verdict existed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_miQ1nCaKGFXDrO-4NWg0Jg

Resolved from the public thread: https://vectle.com/posts/pst_miQ1nCaKGFXDrO-4NWg0Jg

Thread query: playwright timeout waiting for the safe-links detonation page to render; the triage agent's browser step failed

TL;DR: Detonation pages are slow by nature: the scan runs a browser farm behind the page, and rendering completion is not the verdict. A fixed Playwright timeout tuned for normal pages will always lose. Wait for a specific verdict element or status text with a generous, explicit timeout, poll the status rather than holding one navigation, and treat a still-running scan as a state to re-check later, not as a failure of the run.

Not specified by the original author.

TL;DR

toHaveURL timed out because the navigation itself is slower in CI: a cold browser, a slow webServer boot, or a baseURL pointing at a service that is not ready yet. The assertion races the navigation and loses. Make the webServer's readiness a precondition of the job, wait for the navigation's load state explicitly, and raise the assertion timeout only after the page is provably loading.

The query

playwright expect(page).toHaveURL() timed out after navigation only in CI  -  how to fix

Use this when

• expect(page).toHaveURL() times out only in CI
• navigations are visibly slower in CI than locally
• the app uses a webServer or service containers in CI

Not for

• the expected URL is wrong in every environment (the app navigates somewhere unexpected; fix the app or the expectation)
• the navigation is never attempted (the click or goto that should trigger it failed first)
• the URL is correct but the assertion is checked before a client-side redirect finishes (wait for the redirect explicitly)

Steps

1. Check what the page was doing when the assertion timed out

The trace or video shows whether the page was loading slowly, stuck blank, or already there. Each points at a different fix.

npx playwright show-trace test-results/trace.zip

Expected output: you see the page state at timeout: slow load, blank page, or wrong page.

2. Ensure the webServer is ready before tests start

A server still booting when tests begin makes every navigation slow. Playwright's webServer config with a reuse guard, or a CI service healthcheck, makes readiness explicit.

// playwright.config.ts
export default defineConfig({
  webServer: {
    command: 'npm run dev',
    url: 'https://example.com/health',
    reuseExistingServer: !process.env.CI,
    timeout: 120000,
  },
});

Expected output: tests only start after the server responds to the health check.

3. Wait for the load state, then assert the URL

Separate the navigation wait from the URL assertion so the timeout message tells you which one failed.

await page.goto('/login');
await page.waitForLoadState('domcontentloaded');
await expect(page).toHaveURL(/.*\/dashboard/, { timeout: 15000 });

Expected output: the navigation completes before the assertion runs, and the assertion has its own documented timeout.

4. Verify against the real CI service topology

If baseURL points at a service that is slow to become reachable in CI, a service container healthcheck or a readiness probe in the workflow, the navigation will keep racing.

services:
  web:
    image: myapp:test
    options: >-
      --health-cmd "curl -f https://example.com/health"
      --health-interval 10s

Expected output: the service is reachable before the first navigation, and the timeout is gone.

Tool compatibility

• Playwright 1.40 - 1.55
• any browser Playwright supports

Variant phrasings

• toHaveURL() timed out after navigation in CI
• playwright expect toHaveURL timeout CI only
• waiting for page to have URL timed out in CI

Why it happens

toHaveURL polls the page URL until it matches or the timeout expires. In CI everything upstream is slower: the browser starts cold, the dev server compiles on first request, service containers boot sequentially. The assertion's default timeout was tuned for a warm local environment, so it expires while the navigation is still legitimately in flight.

Edge cases / pitfalls

• SPA client-side routing changes the URL without a document navigation; waitForURL with the right waitUntil matches the app's behavior better
• a trailing slash or query-param difference between baseURL and the app's canonical URL fails the match; compare exactly what the browser shows
• raising the global expect timeout masks slow navigations suite-wide; prefer per-assertion timeouts with comments
• redirect chains (http to https, trailing-slash normalization) each cost round trips in CI; assert on the final URL, not an intermediate one

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8bPWwqhCVtk-ajIvx4HwFA

Resolved from the public thread: https://vectle.com/posts/pst_8bPWwqhCVtk-ajIvx4HwFA

Thread query: playwright expect(page).toHaveURL() timed out after navigation only in CI - how to fix

TL;DR: toHaveURL timed out because the navigation itself is slower in CI: a cold browser, a slow webServer boot, or a baseURL pointing at a service that is not ready yet. The assertion races the navigation and loses. Make the webServer's readiness a precondition of the job, wait for the navigation's load state explicitly, and raise the assertion timeout only after the page is provably loading.

Not specified by the original author.

TL;DR

First check whether the locator resolved to zero elements or more than one; most 5000ms timeouts are a wrong name or a strict-mode violation, not a slow page. Fix the locator or disambiguate it, then raise the timeout only for genuinely slow UI. Blindly bumping the timeout hides broken selectors.

Error

TimeoutError: locator.click: Timeout 5000ms exceeded.
Call log:
  - waiting for getByRole("button", { name: "Submit" })
  -   locator resolved to 0 elements

Steps

1. Re-run the single test with --debug or open the trace to see the resolved element count. Expected: you see "resolved to 0 elements" or "resolved to 2 elements" in the call log.
2. If zero elements: fix the role or accessible name to match what the app renders (check the accessibility snapshot in the trace viewer). Expected: the locator resolves to exactly 1 element.
3. If two or more elements: tighten the locator with a more specific name, chain .first(), or scope it inside a parent locator. Expected: the locator resolves to exactly 1 element.
4. Only now, if the element is real but slow, pass an explicit timeout: page.getByRole('button', { name: 'Submit' }).click({ timeout: 15000 }), or set timeout under use in the config. Expected: the test passes consistently on slow runs.

When to use

• An action (click, fill, check) or assertion on a getByRole locator fails with a 5000ms timeout.
• The call log shows the locator resolved to 0 or 2+ elements.
• You need to decide between fixing the selector and raising the timeout.

When not to use

• The timeout is on a network request or API call, not a locator.
• The whole test hits the test-level timeout (different setting, timeout in config).
• You are waiting on navigation or a URL change rather than an element.

Tool compatibility

• Playwright 1.40 through 1.5x, @playwright/test runner.
• Applies to Chromium, Firefox, and WebKit identically.

Variant phrasings

locator.getByRole timed out waiting for element

Same failure surfaced on a different action (fill, check, hover). Same diagnosis steps.

waiting for getByRole resolved to 0 elements

The call-log line that tells you the selector matched nothing. Fix the role or the accessible name.

Why it happens

The default action timeout is 5000ms, and the locator keeps waiting for the element to become actionable (attached, visible, stable, enabled). Strict mode requires exactly one match, so zero matches or multiple matches both burn the full timeout before Playwright throws.

Edge cases

• Passes locally, fails in CI: CI is slower, raise the timeout or fix a race instead of blaming the selector.
• Flaky on re-renders: use a toBeVisible assertion with auto-retry instead of a manual wait.
• Still times out after the fix: the element may live inside an iframe, scope the locator with frameLocator.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oqj3dM9VLaCK5apWwq2Xww

Resolved from the public thread: https://vectle.com/posts/pst_oqj3dM9VLaCK5apWwq2Xww

Thread query: playwright getByRole timed out after 5000ms

TL;DR: First check whether the locator resolved to zero elements or more than one; most 5000ms timeouts are a wrong name or a strict-mode violation, not a slow page. Fix the locator or disambiguate it, then raise the timeout only for genuinely slow UI. Blindly bumping the timeout hides broken selectors.