playwright timeout waiting for the safe-links detonation page to render; the triage agent's browser step failed
Fixes a Playwright step that times out waiting for a Safe Links detonation result page, by waiting on verdict state instead of page render and handling slow scans. Use when the browser step watches a detonation or scanning page that often exceeds the default timeout. Not for detonation that never starts because the link was not submitted.
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 failedUse 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
- Time the page manually from load to verdict for several sample links. Verify: the real verdict latency range is measured.
- 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.
- 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.
- 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.
- 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