Posting in case others are still hitting this after the "Increased invocation failures for Hobby Team functions" incident (started ~13:26 UTC on 2026-07-17, fix stated deployed at 14:27 UTC).

What I saw: Every fresh deployment during the incident window returned 500s on every route: Vercel Runtime Error: failed to load env vars: EnvFileReadError(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Build logs were completely clean every time — full correct Next.js route manifest, no errors. Purely a runtime failure. This happened on both manual CLI deploys and independent GitHub-integration auto-deploys of the same commit, so it wasn't anything specific to how I was deploying.

After the stated fix (14:27 UTC): Redeployed and the symptom changed — instead of the 500, every route (including static pages, not just API routes) started returning: X-Vercel-Error: NOT_FOUND

The deployment itself reported readyState: READY, readySubstate: PROMOTED, correctly-populated alias array, aliasError: null — every piece of metadata said it was healthy — but the edge layer couldn't route to it at all. Zero runtime log entries for it, meaning requests never reached a function. Confirmed this wasn't just my client caching an old response by waiting 7+ minutes and re-checking.

The whole time, a deployment built ~2 days earlier kept serving correctly without any changes on my end, which is how I kept production stable while investigating.

Support interaction (AI-assisted support chat):

First response, after I sent a detailed diagnostic writeup, identified the incident correctly:

"I've identified the issue. Your problem is directly caused by an ongoing platform incident affecting Hobby plan function invocations... A fix has been deployed (as of 14:27 UTC) and we're continuing to monitor... Try redeploying now — a fresh deployment after the fix should work correctly."

After I reported it was still broken post-fix (with the new NOT_FOUND evidence above), the follow-up confirmed the same finding independently by pulling the deployment directly:

"I can confirm exactly what you're describing — your deployment shows: readyState: READY with readySubstate: PROMOTED, aliasAssigned: true with all three aliases correctly listed, aliasError: null... Yet despite all metadata showing a healthy, correctly-aliased deployment, the edge layer is returning NOT_FOUND before any application code is invoked. This is a clear platform-level routing inconsistency that requires internal investigation."

They then opened an internal support case with the deployment IDs and this diagnosis attached, so it's being tracked — posting here in case anyone else on Hobby is still seeing the post-fix NOT_FOUND behavior and hasn't connected it to this incident yet, or wants to compare notes.

Anyone else run into the same thing after the "fix" landed?