time-of-click url verdict stuck on pending for hours
Clears a time-of-click URL verdict stuck on pending, deciding user impact and checking scan service health and link age. Use when clicks show a verdict pending state for hours on a specific link. Not for blocks with a final malicious verdict.
TL;DR
A pending verdict that never resolves means the click-time scan queued and lost the job, the link target stalls analysis, or the scanning service is degraded. For the affected user the practical question is whether the destination can be verified another way. Check service health, test the URL in an external scanner, and if it is a needed legitimate link, allow it narrowly rather than leaving users at a dead page.
time-of-click url verdict stuck on pending for hoursUse this when
- A user click lands on a scanning page that stays pending for hours.
- Several unrelated links are stuck pending at the same time, suggesting a service issue.
Not for this skill when
- The verdict resolves after a short wait. That is normal detonation time.
- The link is confirmed malicious in the pending period. Keep it blocked.
Steps
- Record the exact URL, the time of first click and how many users are affected. Verify: scope is one link or many.
- Check the mail platform service health for URL scanning degradation during the window. Verify: a service incident is confirmed or ruled out.
- Analyse the URL in an independent scanner to get a current verdict. Verify: you have a verdict from at least one working source.
- If the link is verified legitimate and needed, add a time-boxed tenant allow for the exact URL or domain with an owner. Verify: the exception is narrow and dated.
- Have an affected user click again and confirm resolution, then diary the exception for removal. Verify: access works and the follow-up is scheduled.
Variant phrasings
safe links verdict pending stuck scanning page
The stuck verdict variant.
time of click url check pending hours service health
The service health variant.
Compatibility: Defender Safe Links click-time verification and service health reporting.
Why it happens
Click-time verdicts are computed on demand and cached. A job lost between queue and cache leaves a link in permanent pending, because nothing re-triggers the scan while the cache entry says a verdict is coming.
Edge cases / pitfalls
- Re-sending the message with a fresh copy of the link often resolves a single stuck verdict, since the new copy queues a new scan.
- Mass pending states are almost always service-side. Report them rather than building exceptions.
- Pending is not a clean verdict. User guidance should treat a stuck scan as a stop, not a pass.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstlTrrcFzaox7IkV28QAA3A