Fix Dynamic Server Usage Error in Next.js App Router

Your build fails, or a route logs at runtime:

Dynamic server usage: Route /dashboard couldn't be rendered statically
because it used `cookies`.

(Swap cookies for headers, searchParams, or no-store fetch.) This is DYNAMIC_SERVER_USAGE. It is not a bug — it's Next.js telling you a route it wanted to prerender at build time depends on request-time data. The fix is a decision: should this route be dynamic, or should it not need that data at all?

The mental model: build time vs request time#

• Static rendering = the route is rendered at build time, cached, CDN-shareable.
• Dynamic rendering = the route is rendered per request.

The following are dynamic functions — they depend on the incoming request and force dynamic rendering:

• cookies() and headers() (from next/headers)
• searchParams (the page prop)
• draftMode()
• a fetch(..., { cache: 'no-store' }) (or revalidate: 0)

Per the docs: "During rendering, if a dynamic function or uncached data request is discovered, Next.js will switch to dynamically rendering the whole route." Normally that switch is automatic and silent — Next throws DynamicServerError internally and catches it. You see the error "when it's uncaught" — typically because the route was forced static (dynamic = 'error', a static route handler, generateStaticParams, sitemap/metadata files) while a child still calls a dynamic API, or the call ran outside Next's tracked async context.

Fix 1 — Opt into dynamic rendering (when the data IS request-specific)#

// app/dashboard/page.tsx
export const dynamic = 'force-dynamic'

The docs describe this as forcing "routes being rendered for each user at request time... equivalent to getServerSideProps() in the pages directory." This is the right fix when the route genuinely needs per-request data (the user's session, a header, query params).

export const revalidate = 0 achieves the same dynamic outcome via the caching model. Both are valid; force-dynamic is the more explicit switch.

Fix 2 — Remove the dynamic dependency (when it SHOULD be static)#

If the data isn't actually request-specific, don't go dynamic — fix the cause so the route stays fast and cacheable:

• Reading a cookie you don't need? Remove the cookies() call.
• Fetching with cache: 'no-store' for data that rarely changes? Switch to cache: 'force-cache' or revalidate: N.
• Want it fully static? export const dynamic = 'force-static' forces cookies(), headers(), and useSearchParams() to return empty values.

Fix 3 — Isolate the dynamic part in Suspense#

Keep most of the page static and stream only the request-time piece:

import { Suspense } from 'react'
 
export default function Page() {
  return (
    <>
      <StaticHeader />
      <Suspense fallback={<Skeleton />}>
        <UserPanel />   {/* this one reads cookies() */}
      </Suspense>
    </>
  )
}

Route segment config reference#

export const dynamic = 'auto'      // 'auto' | 'force-dynamic' | 'error' | 'force-static'
export const revalidate = false    // false | 0 | number  (Node.js runtime only)
export const dynamicParams = true  // true | false

Values must be statically analyzable — revalidate = 600 is valid, revalidate = 60 * 10 is not.

Official references: dynamic-server-error, app-static-to-dynamic-error, route segment config, Next.js 15 blog.

Related Articles#

• Next.js 15 Caching, Explained
• Fix Stale Cache and Revalidation in Next.js
• Fix revalidatePath Not Working in Server Actions
• Next.js App Router Complete Guide

Frequently Asked Questions#

What causes "Dynamic server usage" in Next.js?#

A route Next wanted to prerender called a dynamic function — cookies(), headers(), draftMode(), searchParams, or a no-store fetch — which needs the incoming request. Next normally switches to dynamic rendering automatically; the error surfaces when that switch is blocked or the call ran outside Next's tracked context.

How do I make a Next.js route dynamic?#

Add export const dynamic = 'force-dynamic' (or revalidate = 0) to the segment. It renders per request — the App Router equivalent of getServerSideProps.

Should I always add force-dynamic?#

No. If the data isn't request-specific, remove the dynamic dependency so the route stays static and fast. force-dynamic is right only when the route must render per request.