Blob client-token writes return 503 — dashboard upload on same store works - Help

Team/Projekt: iron-voice-ai-studio / ivais-dashboard

Betroffene Stores: store_31fpXSbf4s27XiTQ (ivais-dashboard-blob) und store_8zZ25ntP8fXEB05t (ivais-dashboard-blob-v2, brandneu angelegt zum Ausschließen eines store-spezifischen Defekts, zeigt exakt dasselbe Verhalten).

Kernbefund: Ich habe heute den entscheidenden Vergleichstest gemacht. Upload über die Vercel-Dashboard-Oberfläche selbst (Manage Blobs -> Upload, session-authentifiziert): PUT https://vercel.com/api/blob?pathname=diag-test.png -> 200 OK, Datei ist im Store sichtbar. Derselbe Store, wenige Minuten später, aber über den Client-Token-Weg (upload() aus dem npm-Paket "vercel/blob/client" (Scope "vercel"), Token via handleUpload-Server-Route, Standard-Next.js-Pattern): POST https://vercel.com/api/blob/mpu?pathname=diag-test-app.png -> 503 Service Unavailable (SDK-intern automatisch wiederholt, ebenfalls 503).

Schreibzugriff auf den Store funktioniert also grundsätzlich. Das Problem tritt spezifisch bei extern signierten Client-Tokens auf (generateClientTokenFromReadWriteToken / handleUpload) — sowohl bei multipart: true (/api/blob/mpu) als auch bei einfachem PUT (/api/blob, in einem früheren Test ebenfalls mit 503 reproduziert).

Weitere Fakten: Read-Operationen (Client-Token-Erzeugung via handleUpload) funktionieren einwandfrei (200 OK), nur der eigentliche Schreib-Request mit diesem Token schlägt fehl. OPTIONS-Preflight liefert 200, die eigentliche PUT/POST-Anfrage liefert einen echten 503, kein Netzwerkfehler, keine CORS-Blockade. Reproduziert identisch auf zwei Geräten (Desktop, Mobilgerät) und getrennten Netzwerken (Heim-WLAN, mobile Daten). Ein zweiter, komplett neu angelegter Store zeigt exakt dasselbe Verhalten. Zahlungsmethode ist im Team-Account hinterlegt und aktiv, kein Billing-Problem. Storage-Nutzung liegt bei 0 B, weit unter allen Hobby-Plan-Limits. Der Advanced-Operations-Zähler im Store-Dashboard steigt mit jedem fehlgeschlagenen Versuch. Vercels Statusseite zeigt "Alle Systeme einsatzbereit". Kein "Store ist blockiert"-Hinweis im Dashboard.

Reproduktion: 1) upload() aus dem Client-SDK mit handleUploadUrl auf eine Server-Route, die handleUpload implementiert. 2) Client-Token wird erfolgreich erzeugt (200 OK). 3) Client sendet POST https://vercel.com/api/blob/mpu?pathname=... mit gueltigem Authorization-Bearer-Header. 4) Antwort: 503 Service Unavailable. 5) Zum Vergleich: Upload derselben Datei ueber die Vercel-Dashboard-UI auf denselben Store -> 200 OK.

Frage: Hat jemand ein aehnliches Verhalten gesehen, speziell diese Diskrepanz zwischen Dashboard-Upload (geht) und Client-Token-Upload (503)? Gibt es einen bekannten Bug oder eine Account-/Team-Einstellung, die extern signierte Blob-Client-Tokens anders behandelt als session-authentifizierte Requests?

Resolved, and it turned out to be my own misconfiguration rather than a Vercel bug. Posting the full explanation in case someone else lands here with the same symptoms.

Root cause: the Blob store was created as a private store, while my client code calls upload() with access: "public". In the "Create Blob Store" dialog, Access defaults to Private (it even carries the "Recommended" badge), and it cannot be changed afterwards. The store settings page offers rename, transfer, rotate credentials and delete, but no access toggle.

Against a private store the API answers: 400 bad_request, "Cannot use public access on a private store. The store is configured with private access."

I reproduced it cleanly outside the browser. I minted a client token from my own production handleUpload route (200 OK), then called the Blob API directly with curl. With header x-vercel-blob-access: public I get 400 on both PUT /api/blob and POST /api/blob/mpu. With x-vercel-blob-access: private I get 200 OK and the file is written. So Blob writes were never broken, and externally signed client tokens were never the problem.

Why I misdiagnosed this as a 503 outage: the SDK throws BlobServiceNotAvailable, whose message is "The blob service is currently not available. Please try again.", for any failed fetch. That reads like a service incident. My "dashboard upload works but client-token upload fails" comparison pointed the same wrong way, because the dashboard writes using whatever access mode the store actually has. The difference was never the authentication method.

One more gotcha for anyone doing something similar: simply switching my code to access: "private" would not have helped either, because the media URL has to be fetchable by Instagram's servers, and a private blob URL returns 403 to an anonymous request. The real fix was creating a new store with Access set to Public, connecting it to the project and redeploying. Uploads now return 200, and the resulting URL serves 200 to an anonymous GET and HEAD.

Suggestion for the Vercel team: surfacing BlobServiceNotAvailable for what is really a 400 configuration error sends people looking for an outage. Passing through the API's own message would have saved several days here.

Apologies for the noise, and thanks to anyone who spent time on the original post.

Team/Projekt: iron-voice-ai-studio / ivais-dashboard

Resolved, and it turned out to be my own misconfiguration rather than a Vercel bug. Posting the full explanation in case someone else lands here with the same symptoms.

Against a private store the API answers: 400 bad_request, "Cannot use public access on a private store. The store is configured with private access."

Apologies for the noise, and thanks to anyone who spent time on the original post.