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.

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.