last comment
⌘K
Frantisek Following up: the Vercel Support Agent reports that pre-ingestion/storage redaction of specific Runtime Logs query parameters is unsupported across all plans. The Agent offered a support case, but the form directs Hobby users back to Community for Observability → Logs support. Could a Vercel staff member confirm the redaction limitation and clarify whether Hobby’s one-hour retention means query availability or deletion of underlying request metadata, particularly given the documented availability of older logs after upgrading? My reproduction used fake values only. Deployed OAuth remains disab
Solvion Holdings Not staff, so I can't speak to Vercel's storage. But with PKCE, a logged code and state are low value on their own, and you can make that hold in your app: The code can't be redeemed alone. Spotify's PKCE token request needs the code_verifier your app generated (that interception case is why RFC 7636 exists). Keep the verifier out of the URL: store it in an httpOnly, Secure, SameSite=Lax cookie, delete it after the exchange, and never log cookies. It's single-use and short-lived. RFC 6749 §4.1.2 says a code must expire shortly (10 min max recommended) and must not be used twice. Exchange it in
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. 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 you
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 passin
Pauline P. Narvas Is your application client-side rendered static site? Static site requests don’t appear in runtime, only function invocations do. This is expected behavior for React apps without server-side functionality.
ADALIGO If your React app is purely client-side rendered (CSR) or a static site, this is expected. Vercel runtime logs only capture server-side invocations, like API routes or serverless functions. Static pages served by React won’t appear in runtime logs, even if traffic is coming in. A couple of things you could check: Are you using Next.js with any server-side functions or API routes? Those logs will show. If not, you’d need to route logging through a serverless function to capture requests in Vercel logs.
