Next.js 'Application error: a server-side exception has occurred' — Find the Real Error (Digest Explained)

Your Next.js app works locally. You deploy it, open a page, and get this instead:

Application error: a server-side exception has occurred (see the server logs for more information). Digest: 1389973523

No message, no stack trace, no file name. Just a number. This is one of the most-reported production errors in the Next.js GitHub issues, and the cause is almost never in the message you can see, because there is no message to see.

Why Next.js hides the error

In production builds, Next.js deliberately omits the error message from anything sent to the browser, so a server-side failure cannot leak internals (database errors, file paths, query text) to your visitors. Instead it attaches a digest: a hash that identifies the error.

The digest is not the error. It is a label that appears in two places:

1. On the page the visitor sees.
2. Next to the real error and stack trace in your server logs.

The whole debugging job is matching the first to the second.

Step 1: find the digest in your server logs

The full error is printed on the server, not in the browser. Search your logs for the digest string, for example 1389973523.

• Vercel: Project → Logs (runtime logs). Search for the digest or filter to the time of the request. Hobby-plan runtime logs are kept for a short time, so do this soon after the failure (see Vercel log retention).
• Docker: docker logs <container>
• A VPS with pm2: pm2 logs
• Plain next start: the stdout/stderr of the Node process.
• Azure: the app's log stream.

The real cause is often printed on the line just before the generic message. A Prisma error code or a "Ref not found" from a CMS client shows up right there.

Step 2: reproduce it in production mode

Many of these errors only appear after deploying, because next dev is more forgiving. Run what production runs:

next build && next start

If it fails locally in production mode, you can debug it with a normal debugger and no hosting platform involved.

The usual causes

• Missing or wrong environment variables on the server. The most common one. A variable that exists in .env.local but was never set in your host's dashboard.
• A backend or API URL that only works locally. localhost URLs, or services not reachable from the deployed environment.
• Database or ORM problems. For example Prisma on the edge runtime, or a connection limit.
• Mixing static and dynamic rendering. Reading searchParams or cookies in a page that is statically generated.
• A bug in one Next.js version. Occasionally a clean redeploy on a newer patch release fixes it.

Step 3: stop doing archaeology — capture every server error

Searching logs works once. The better fix is to record every uncaught server error with its digest at the moment it happens, so the next one takes ten seconds.

Next.js supports an onRequestError hook in instrumentation.ts (Next.js 15 and later). It runs inside your server for every request error, on any host. FlareLog ships a ready-made hook:

// instrumentation.ts (project root, or src/ if you use it)
import { flarelog } from "@flarelog/sdk";
import { createOnRequestError } from "@flarelog/sdk/next";

const logger = flarelog({ apiKey: process.env.FLARELOG_API_KEY });

export const onRequestError = createOnRequestError(logger);

Each failure is recorded as an ERROR with:

• next.digest, the same number the visitor sees
• the route, route type and router kind (App Router or Pages Router)
• the HTTP method and path, without the query string (query strings often carry tokens)
• the full stack trace

Request headers and cookies are never sent. Now, when a user pastes "Digest: 1389973523", you search that number in FlareLog and land on the exact error, with its stack, regardless of where the app is hosted or how long your host keeps logs.

Use the latest @flarelog/sdk; the hook is in the @flarelog/sdk/next entry point, and the Next.js guide has the details.

Two more places to log

• error.tsx and global-error.tsx. Log error.digest alongside error.message so client-side boundaries leave a trail too. Remember that global-error.tsx must render its own <html> and <body> tags.
• try/catch around risky server code (data fetching, database calls). Log the real error with console.error, so it appears in your logs right next to the digest.

Quick checklist

1. Copy the digest from the error page.
2. Search your server logs for it (or FlareLog, once the hook is in).
3. Read the line above the generic message for the real cause.
4. Check env vars on the server, then backend URLs, then database connections.
5. Reproduce with next build && next start.
6. Add onRequestError so you never have to do steps 1 to 2 by hand again.

Want to try step 6? Start free: 10,000 logs a month, no card. And if you use an AI coding assistant, connect it to your production logs so it can read the error for you.