## TL;DR
Click-time scanning must download and analyse the target, and a large shared file can exceed the scan time or size budget, leaving the user with a timeout instead of a file. Decide what should happen for oversized targets: warn and allow for trusted internal shares, or block for external ones, rather than leaving an accidental timeout behaviour. Check the platform size limits and whether the share is internal or external.

```text
defender safe links url scan failed on large file share url after timeout
```

## Use this when
- Clicking a shared file link ends in a scan timeout or a failed page.
- Large vendor or internal shares fail while normal web links work.

## Not for this skill when
- The file itself is flagged malicious after scanning completes. That is a true verdict, not a timeout.
- All Safe Links clicks time out. That suggests service health, not file size.

## Steps
1. Reproduce with the actual shared link and record target size and the exact timeout behaviour users see. Verify: size and symptom are documented.
2. Check your platform published scan size and time limits and compare with the file. Verify: the file is over the limit, confirming the cause.
3. Determine the trust context: internal tenant share, known partner share, or anonymous external share. Verify: the appropriate policy class for this link is chosen.
4. Configure the intended handling for oversized targets in that class, such as bypassing rewrite for your own SharePoint and OneDrive domains while keeping external oversized links blocked or warned. Verify: the rule matches domain and class, not just size.
5. Retest the original link and an external oversized test link. Verify: each behaves as its class policy intends, with no raw timeout.

## Variant phrasings
### safe links scan timeout large file sharepoint onedrive
The SharePoint variant.
### url detonation size limit oversized file policy
The size limit variant.

Compatibility: Defender Safe Links scanning of SharePoint, OneDrive and Teams file links.

## Why it happens
Detonation trades time for safety, and large files break the budget. Platforms scan files shared inside the tenant through their own file pipeline, so rewriting those links again at click time duplicates work and hits limits the direct path avoids.

## Edge cases / pitfalls
- Anonymous external shares deserve the strictest handling because anyone can host anything behind them.
- A timeout that fails open is a security gap; one that fails closed is an outage. Know which your platform does.
- Users will route around repeated timeouts with personal drives. Fix the policy rather than training around it.

## Provenance

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