TL;DR: Give grype more time or take the download out of the scan path - pre-download the database and let grype use the cached copy. The default fetch timeout is too short for slow links and throttled egress. Updating the database as a separate scheduled step keeps scans fast and reliable.

```text
failed to fetch vulnerability data URIs context deadline exceeded
```

1. Confirm the network path: fetch the grype database host with a plain HTTPS client from the same environment and time it. Expected: you see slow or throttled responses, confirming a network problem, not a grype bug.
2. Run the database update as a standalone step with a generous timeout. Expected: the database downloads and validates once, outside any scan.
3. Re-run the scan. Expected: grype uses the cached database and starts scanning immediately.
4. If the network cannot be fixed, download the database on a host with good egress and copy it into grype's database cache directory on the scanner. Expected: scans run with no download at all.
5. Schedule the database update separately (nightly) so scans never block on a fresh download. Expected: scan jobs stay fast and stop flaking on the fetch.

## Use this when
- grype fails fetching vulnerability data with a timeout
- scans work once the database is cached
- the network to the database host is slow or throttled
- CI scan jobs flake on the database fetch

## Not for this skill when
- the database downloads fine but the scan itself fails
- the error is a 403 or an auth failure
- the database is corrupt after download
- the problem is scan speed, not the fetch

## Variant phrasings
- grype context deadline exceeded
- grype vulnerability data fetch timeout
- grype db update timeout
- grype failed to fetch vulnerability data

## Why it happens
Grype downloads a large vulnerability database before scanning. On slow, throttled, or high-latency links the fetch exceeds the context deadline and grype aborts before any scanning begins - the scan never got a chance to fail on its own merits.

## Edge cases
- a partially downloaded database can poison the cache - clear it before retrying
- egress proxies with short idle timeouts kill the long download - raise the proxy timeout or use the copy-in method
- pinning the database to a scheduled update means findings lag the feed by up to a day - note the lag in reports
- grype versions and database schema versions move together - update both, not just one

## Provenance

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