500 Internal Server Error
The server’s code threw an error or crashed while handling the request, and the real error message is waiting in the server logs.
Also appears as
- Failed to load resource: the server responded with a status of 500 (Internal Server Error)
- AxiosError: Request failed with status code 500
Prompt to fix it
A request to our server returns "500 Internal Server Error". Find the server code that handles that route and the actual error: check the dev server terminal or the host’s function logs, and reproduce it locally if needed. Fix the root cause, whether it’s a missing environment variable in production, unvalidated input, or an unhandled failure from the database or another API. Answer invalid input with a 400, log real errors with context, and return a JSON error the frontend can display. Don’t wrap everything in a catch that returns 200.
Paste into Layerwise or any AI coding tool.
What it means
A 500 is the server’s generic “something broke on my side.” Your request reached the code, and that code threw an error or crashed before it could answer properly. The browser only sees the status, because servers keep error details away from visitors on purpose.
So the useful message lives in the server logs: the terminal running your dev server, your host’s function logs (the Logs tab of a Vercel project, for example), or the Edge Function logs in Supabase. On Vercel, a function that crashes shows the code FUNCTION_INVOCATION_FAILED.
A route that works locally and fails after deploy is very often a missing environment variable. Locally the key sits in .env. In production the code reads undefined, and the first database or API call throws. Check the host’s environment settings before you debug the code.
Common causes
- A required environment variable, such as a database URL or API key, is missing in production.
- The handler throws on unexpected input, for example by reading a field the request body doesn’t have.
- A call to the database or a third-party API fails, and the code doesn’t catch it.
- The code uses a Node.js API or package that the host’s runtime doesn’t support, such as an edge runtime.
How to fix it
- Open the server logs at the time of the failed request and find the stack trace.
- If the logs are empty, run the same request locally and watch the dev server’s terminal.
- Compare the environment variables your code reads with the ones set on the host, add any missing ones, and redeploy.
- Validate the request body at the start of the handler, and answer bad input with a
400and a clear message. - Catch errors from outside services, log them with context, and return a JSON error the frontend can show.
Example fix
// app/api/checkout/route.ts
import { createCheckout } from '@/lib/checkout';
export async function POST(request: Request) {
const secret = process.env.STRIPE_SECRET_KEY;
if (!secret) throw new Error('STRIPE_SECRET_KEY is not set');
const body = await request.json().catch(() => null);
if (!body?.priceId) {
return Response.json({ error: 'priceId is required' }, { status: 400 });
}
try {
return Response.json(await createCheckout(secret, body.priceId));
} catch (error) {
console.error('Checkout failed', error);
return Response.json({ error: 'Checkout failed' }, { status: 500 });
}
}Related errors
All errorsFUNCTION_INVOCATION_TIMEOUT
A Vercel Function ran past its time limit, so Vercel stopped it and returned a 504 in place of your response.
Error 1101: Worker threw exception
Your Cloudflare Worker hit a JavaScript error while handling the request, so Cloudflare showed its error page in place of a response.
Unexpected token '<', "<!DOCTYPE "... is not valid JSON
Your code expected JSON, but the server sent back an HTML page, usually a 404 page or your app’s own index.html.
Blocked by CORS policy
The browser hid a response from another site because that server never said your site is allowed to read it.
Build with an agent that checks its work
The Layerwise agent clicks through the live preview and reads the console, so it catches errors before you do.