#compute

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Chrisrivero Dev Hey, This doesn’t sound like a 404 issue. If the function is hanging for about 60 seconds and then dying with INTERNAL_FUNCTION_INVOCATION_FAILED, I’d first try to confirm whether the function is actually entering your handler in Vercel. Can you add a log as the very first line of the function and see if that appears in the invocation logs? If it does, then I’d start checking what it’s waiting on after that, especially a database connection or anything environment-specific between local and Vercel. If the first log never appears, that points more toward the runtime/startup side rather than your application logic. Since the generated artifact works locally on Node 22/24, I’d definitely want to isolate exactly where execution stops in Vercel before changing more code.

Jacob Paris This is an initialization timeout, failing before your server receives its request. The most likely reason is if `server.listen()` never completes in a way that Vercel can see For zero-config Node servers, Vercel captures your server.listen() call while the module loads and routes traffic to it internally, ignoring the PORT you pass. This removes a layer of overhead by letting Vercel serve your server directly instead of receiving and passing into an internal service. Running the built server.mjs directly with Node skips that step, which is why it works locally. I think it's possible that passing the HOST to your listen call is preventing Vercel from connecting to it, but hard to say for certain without testing. You could try a deployment without that and see if it starts working. Otherwise, to find where your module stops during initialization, add console.log at the very top of your entry file and right before and after server.listen(), redeploy, and check Runtime Logs. If the first log never appears, the module isn't finishing loading. If it appears but the listen log doesn't, listen() isn't being reached during startup

Iankirk99 Update: these logs appear to have stopped at 8:00 UTC August 7th with no code changes or deployments on my end.

Ryu Hi Sbullocks, Since static assets work but every function hangs until timeout, I’d separate “Vercel can route to a function” from “your new runtime code is waiting forever.” First, deploy one tiny endpoint that does not import anything shared from the app: ``` // app/api/ping/route.ts export const dynamic = "force-dynamic" export async function GET() { return Response.json({ ok: true, time: Date.now() }) } ``` If that works, the platform/function routing is fine and I’d look at the changes from the rate-limiting commit: middleware, shared auth helpers, Redis/KV/database clients, external fetches, or env vars that are now awaited before returning a response. If that tiny endpoint also hangs, check whether it is really included in the latest deployment and inspect logs outside the dashboard: ``` vercel inspect <deployment-url> --logs vercel logs <deployment-url> --since 1h ``` For the affected routes, I’d also add timing around each awaited operation: ``` console.time("rate-limit") await checkRateLimit() console.timeEnd("rate-limit") console.time("upstream") const res = await fetch(url, { signal: AbortSignal.timeout(10000) }) console.timeEnd("upstream") ``` A very common cause after adding rate limiting is a server-side call waiting on a missing/incorrect Production env var or an upstream service that is reachable locally but not from the deployed function. The key signal is whether the function logs stop before or after the rate-limit / external API call. Vercel has a useful slow-function debugging command here: https://vercel.com/docs/functions/debug-slow-functions Can you share the first log line before the hang and whether the isolated `/api/ping` route returns immediately?

Ryu Hi JorgY\_, Given your diagnostic output, I’d focus on the Supabase connection type rather than the PHP env vars. The suspicious part is: ``` Database: Supabase Postgres Direct connection Port: 5432 pdo_pgsql_loaded: true sslmode=require Works locally, fails on Vercel ``` Supabase direct database connections use IPv6 unless you have the IPv4 add-on enabled. Vercel serverless functions are commonly the case where the direct `db.<project-ref>.supabase.co:5432` connection fails, even though the same credentials work locally. I’d switch the deployed PHP API to the Supabase **Shared Pooler / Supavisor** connection string instead of the direct connection string. In Supabase: ``` Project → Connect → Connection string → Pooler ``` For serverless functions, try the transaction pooler first: ``` host: aws-<region>.pooler.supabase.com port: 6543 user: postgres.<project-ref> database: postgres sslmode: require ``` So your PDO DSN would be shaped more like: ``` $dsn = "pgsql:host={$host};port=6543;dbname={$database};sslmode=require"; $pdo = new PDO($dsn, $username, $password, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, ]); ``` Make sure the username changes too. For the pooler it is usually `postgres.<project-ref>`, not just `postgres`. Supabase explains the IPv4/IPv6 difference here: https://supabase.com/docs/guides/troubleshooting/supabase--your-network-ipv4-and-ipv6-compatibility-cHe3BP One more thing: temporarily log the real PDO exception message, but not the password or full connection string. The difference between `connection refused`, `timeout`, and `password authentication failed` will confirm whether this is network/IPv6 or credentials.

Pauline P. Narvas Currently, Hobby plans do send email notifications as you approach usage limits, but you’re right that there’s no detection for unusual spikes or patterns. The Spend Management feature with customizable alerts is only available on Pro plans. I’ll pass this feedback along to our product team. In the meantime, here are some tips to help monitor usage: - Check your Usage Dashboard regularly to spot trends - Consider implementing client-side checks before routing to Edge Functions - Use environment variables to easily toggle telemetry endpoints - For critical projects, Pro plans offer Spend Management with webhooks that can trigger maintenance mode Thanks for helping us improve Vercel! Your use case of catching runaway bugs early is a great example of why this feature would be valuable for Hobby users.

Pauline P. Narvas Thanks for sharing this, @jayarbrul01-8727!

Anshuman Bhardwaj Thanks @shige. I agree having sandbox in multiple regions will be so amazing! Passing on this feedback to our team.

Tadashi Shigeoka Thank you for the quick response, @anshumanb san! Looking forward to seeing multi-region support come to Vercel Sandbox.

Felix421 I would also like to second this request. I am with a cloud consulting firm in Germany and we would love to adopt vercel sandbox as our AI platform solution. We are as of now unfortunately unsure due to the lack of EU hosting. Do you already have distinct plans to expand sandboxes availability? Have a great day everyone! Best regards Felix

Lucas Vieira Thanks for sharing the workaround. The next.config.ts file tracing approach works, but it’s undocumented and breaks whenever Next.js changes its bundling behavior (which happens more often than you’d think). For anyone reading this who doesn’t want to maintain that config, there are alternatives that avoid the Chromium binary problem entirely: * Client-side: jsPDF or html2pdf.js for simple PDFs (limited CSS support, but zero server deps) * https://gotenberg.dev — open source, self-hosted. Run Chromium in a Docker container and call it via HTTP from your serverless function. Full quality, you manage the infra. * https://pdfshift.io — hosted API with a free tier. * https://presa.dev — hosted API I built, also has a free tier (100 PDFs/month). The Chromium-on-serverless approach will keep breaking with every Node/Next.js/Chromium version bump. An HTTP call doesn’t have that problem.

Jacob Paris How are you injecting the cookie? Can you add it in a request interceptor instead so it resolves at request time instead of ahead of time?

Bharathrnair7 1528 async function processQueue(newAccessToken?: string, error?: any) { while (requestQueue.length) { const queued = requestQueue.shift(); if (!queued) continue; if (error) { queued.reject(error); } else { try { // Explicitly set the new token on the queued request config // instead of relying on the interceptor (which reads stale cookies) if (newAccessToken) { queued.config.headers = { ...queued.config.headers, Authorization: \`Bearer ${newAccessToken}\`, }; } const response = await http(queued.config); queued.resolve(response); } catch (err) { queued.reject(err); } } } } try { const newAccessToken = await handleTokenRefresh(); // process all queued requests with the new token await processQueue(newAccessToken); // retry the original request with the new token explicitly originalRequest!.headers.Authorization = \`Bearer ${newAccessToken}\`; const retryResponse = await http(originalRequest!); response.data = retryResponse.data.Output; response.messages = \["Your request was processed successfully."\]; } finally { isRefreshing = false; } im injecting the cookies, in interceptor itself

Jacob Paris We have a whole set of guides including chatbot examples here that answer all of your questions https://ai-sdk.dev/docs/ai-sdk-ui/overview

system Hi there, sorry that you are facing this issue. You can open a **Billing** support case from https://vercel.com/help to get your refund. If you've already opened a case, rest assured our support team will help you as soon as they get to the ticket. > Customers on all plan types are welcome to open a new case for any billing issue. Just describe the problem to the AI chat bot and click the “Create Case” button that appears at the bottom of the chat window. The AI will autofill the form based on the info provided. Then, you can review and adjust any info in the form before submitting it to reach our billing experts.