Two catches:

• it was 1-2 days, but note that starting the eval happens immediately after the merge, so that is the point where the git hash gets fixed already, even if the channel advances to it a day or two later
• the new queue runner appears to be way way faster in this respect

$ curl -s https://cache.nixos.org/gypp7g48p2fcpjx952i84dhw4ak95np1.narinfo --show-headers
HTTP/2 404 
server: Varnish
retry-after: 0
content-type: text/plain
accept-ranges: bytes
date: Mon, 22 Jun 2026 06:06:44 GMT
via: 1.1 varnish
x-served-by: cache-vie6368-VIE
x-cache: MISS
x-cache-hits: 0
access-control-allow-origin: *
content-length: 3

404⏎                                                                                                          

Also this one, it was 7 days old commit

8c14fa3ccacd..ea68a74f45ad  nixpkgs-26.05-darwin

In reply to @vcunat:matrix.org
It's certainly fine not to cache those, as long as it doesn't cost us much.

We do get charged for 404s and 200s just the same.

Idk what the ratio between uncached 404s and 200s is. We can look this up in fastly.

Caching 404s definitely saves money. But idk how much.

But we currently don't cache them exactly so that we don't have read after write inconsistencies.