Transient 501 "internal error" on Netlify Blobs writes from Edge Functions - size-independent, ~5% of attempts

Support
1

Site: tripdippity-app.netlify.app
Where: Edge Function (supply-enumerate) writing JSON to a site-wide Blobs store via @netlify/blobs v10.x (getStore + setJSON)

What happens: A percentage of Blobs writes from our edge function fail with: “Netlify Blobs has generated an internal error (501 status code).” Reads work normally. The failures are transient and size-independent - in a controlled probe ladder (0KB / 1KB / 5KB / 10KB / 24KB / 50KB payloads, repeated runs), we measured 17 successes / 1 failure (~5.6% per attempt), and notably a 1KB write failed in the same run where a 50KB write succeeded - so this is not a payload-size limit. In two additional runs the function invocation itself returned an outright HTTP 500. The Edge Functions limits documentation lists no outgoing-payload ceiling (checked 2026-07-22), and we found no current status-page incident matching this.

Impact before we caught it: the SDK failure was easy to swallow silently (a caught exception), so cache writes failed invisibly for an unknown period - stale data served for up to our 30-day TTL. We have since added read-after-write verification and a 3-attempt retry on our side, which mitigates it (~0.02% residual), but the underlying transient appears to be on the platform side and seemed worth reporting.

Repro available: our probe endpoint performs the write ladder and returns per-write verified/error results in the JSON response - happy to share details or run it on request.

Questions: (1) Is a ~5% transient 501 rate on Blobs writes from the edge runtime a known issue? (2) Is there any undocumented constraint on Blobs writes from Edge Functions we should design around? (3) Anything you’d like us to capture next time it fires (request IDs, timestamps, region)?

2

Correction on our own figures: the “17 ok / 1 fail (~5.6%)” tally and the “1KB failed while 50KB succeeded” observation come from two separate runs — the 17/1 tally is from three later ladder runs (its single failure was a 50KB write); the 1KB failure was in the first bisect run, where 50KB succeeded. Combined across all runs it’s roughly 2 failures in 24 attempts (~8%). The size-independence point stands and is if anything better supported: across runs, the failures landed on different payload sizes (1KB once, 50KB once).

3

Following up — this is still reproducible at roughly the same ~5–8% rate, and remains size-independent. We’ve since worked around it on our side with verified writes plus a 3-attempt retry, so this report is now purely upstream diagnostics for your team. I have request IDs, regions, and timestamps for the failing attempts captured and ready to share if a Netlify engineer wants them. Happy to provide anything else that helps reproduce.