Extremely High CPU Usage from next-server in Production (Next.js 15.4.3)

[sayou]

Summary

Hi,

I’m experiencing very high CPU usage in production when running my Next.js app with next start. The issue began recently.

Environment

• Next.js Version: 15.4.3
• Node.js Version: 18.18.2
• PM2 Version: 5.3.0
• OS: Ubuntu 22.04
• Deployment Target: Self-hosted VPS
• Start Command: next start (managed by PM2)
• Package Manager: Yarn (berry)
• Build Command: NODE_ENV=production yarn build
• App Type: Custom app (not using Vercel)

Symptoms

After deployment, CPU usage spikes significantly:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
855183 appuser   20   0   31.7g 639880  61068 R 103.3   1.9   5:01.09 next-server

• No specific page or route causes this.
• No infinite loops or abnormal API polling detected.
• Behavior persists even when traffic is low.

CI/CD Context

Deployment is fully automated using GitHub Actions. Here’s a summary of what happens after a commit:

- name: Build
  run: NODE_ENV=production yarn build

- name: Deploy
  run: |
    rsync ./ to server
    ssh server '
      cd project &&
      yarn install --production &&
      pm2 restart "my-app"

'

Question

• What could cause next-server to consume 100%+ CPU in a typical production next start run?
• Are there any known regressions or debug flags I should use to trace this more deeply?
• Thanks for your help! Happy to share a minimal reproduction if needed.

Additional information

No response

Example

No response

[SametDulger]

Hi @sayou,

High CPU usage by next-server in production can stem from various causes. Here are some common areas to investigate and suggestions:

Possible causes
Excessive server-side rendering (SSR) workload
If many pages use SSR or server components with heavy computation or blocking calls, CPU can spike even with low traffic.

Infinite loops or expensive loops in React server components or API routes
Sometimes subtle bugs cause infinite re-renders or data fetching loops.

Misconfigured ISR (Incremental Static Regeneration)
Heavy ISR revalidation or misconfigured cache settings can cause frequent rebuilds.

Memory leaks or unclosed database connections
These can cause resource exhaustion and high CPU.

Next.js or Node.js version issues
Check changelogs for known regressions in 15.4.3 or Node.js 18.18.2.

Heavy or blocking middleware
Custom middleware running on every request with expensive logic.

Debug tips
Use NODE_DEBUG=next:* environment variable to enable verbose Next.js logging.

Profile CPU usage with clinic.js or Node’s built-in --inspect and profiling tools.

Add instrumentation/logging in server components, API routes, and middleware to narrow down hotspots.

Test with a minimal reproduction (simple app with no custom logic) to isolate if issue is app-specific or Next.js core.

Check for large or frequent ISR revalidations.

Suggestions
Upgrade to the latest Next.js patch (check if 15.4.x has fixes).

Monitor and optimize server components and API routes for expensive work.

Review your ISR and caching strategies.

Consider horizontal scaling or increasing instance size if legitimate load.

Investigate PM2 settings (max memory, restarts).

If possible, switch to Vercel or a managed platform to isolate infrastructure issues.

If you can share a minimal repro or profiling logs, the community can help dig deeper.

[sayou]

Hello @SametDulger

Thank you for your time and valuable input on this issue. Apologies for the delay in my response.

Following the recommendation, I profiled the application under load using clinic.js to investigate the CPU spikes. I ran the following command:

clinic doctor --on-port "npx autocannon -c 200 -d 30 http://localhost:\$PORT" \
  -- node node_modules/next/dist/bin/next start -p 3000

The clinic doctor report confirms a significant performance issue, showing a sharp increase in Event Loop Delay and Event Loop Utilization under load.

Additionally, our production PM2 logs show a high frequency of ResponseAborted errors during these periods, which suggests that the server is unable to process requests before the client connection is terminated.

2025-08-09 12:12:12 +00:00: [ResponseAborted: ]
2025-08-09 14:14:00 +00:00: [ResponseAborted: ]

To provide more context, I'm sharing the relevant parts of our configuration below.

Middleware:

Our middleware handles i18n routing, protected routes, and security headers. My primary suspicion is that a bottleneck might exist here, as it runs on most incoming requests.

import { localePrefix } from "@/utils/navigation";
import { protectedRoutes } from "@/config/protected-routes";
import createMiddleware from "next-intl/middleware";
import { NextRequest, NextResponse } from "next/server";

// Reusable CSP Directives
const CONTENT_SECURITY_POLICY = [
  "default-src 'self'",
  "connect-src 'self' https://api.example.com https://www.google.com https://www.google-analytics.com",
  "script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com",
  "frame-src 'self' https://www.googletagmanager.com",
  "style-src 'self' 'unsafe-inline'",
  "img-src 'self' data: https://images.example.com",
  "font-src 'self'",
  "object-src 'none'",
  "frame-ancestors 'none'",
  "form-action 'self'",
  "base-uri 'self'",
  "upgrade-insecure-requests"
].join("; ");

const handleI18nRouting = createMiddleware({
  locales,
  defaultLocale,
  localePrefix,
});

function applySecurityHeaders(headers: Headers) {
  headers.set("Content-Security-Policy", CONTENT_SECURITY_POLICY);
  headers.set("X-DNS-Prefetch-Control", "on");
  headers.set("Strict-Transport-Security", "max-age=63072000; includeSubDomains; preload");
  headers.set("X-Content-Type-Options", "nosniff");
  headers.set("Referrer-Policy", "no-referrer, strict-origin-when-cross-origin");
  headers.set("X-Frame-Options", "SAMEORIGIN");
  headers.set("X-XSS-Protection", "1; mode=block");
}

export default async function middleware(request: NextRequest) {
  const { pathname, search } = request.nextUrl;

  // Redirect /defaultLocale to root
  if (pathname === `/${defaultLocale}` || pathname.startsWith(`/${defaultLocale}/`)) {
    const url = request.nextUrl.clone();
    url.pathname = pathname.replace(`/${defaultLocale}`, "") || "/";
    return NextResponse.redirect(url, 301);
  }

  // Check for protected route access
  const isProtectedRoute = protectedRoutes.some(route => pathname.startsWith(route));
  const isAuthenticated = Boolean(request.cookies.get("user")?.value);

  if (isProtectedRoute && !isAuthenticated) {
    const redirectPath = (defaultLocale === "en" || !locales.includes(defaultLocale))
      ? "/"
      : `/${defaultLocale}`;
    return NextResponse.redirect(new URL(redirectPath, request.url), 307);
  }

  // Add custom headers
  const customHeaders = new Headers(request.headers);
  customHeaders.set("x-lang-url", defaultLocale);
  customHeaders.set("x-path", pathname);
  customHeaders.set("x-search", search);

  // Pass through i18n middleware
  const i18nResponse = handleI18nRouting(
    new NextRequest(request.nextUrl, { headers: customHeaders })
  );

  const responseHeaders = new Headers(i18nResponse.headers);

  // Set detected locale cookie
  const detectedLocale = i18nResponse.headers.get("x-next-intl-locale");
  if (detectedLocale) {
    responseHeaders.set(
      "Set-Cookie",
      `NEXT_LOCALE=${detectedLocale}; Path=/; SameSite=Lax`
    );
  }

  applySecurityHeaders(responseHeaders);

  return new NextResponse(i18nResponse.body, {
    status: i18nResponse.status,
    statusText: i18nResponse.statusText,
    headers: responseHeaders,
  });
}

export const config = {
  matcher: ["/", "/((?!api|_next|_vercel|sitemap/|robots\\.txt|manifest\\.webmanifest|favicon(?:\\.ico|\\.svg|(?:-[0-9]+x[0-9]+)?\\.png)|apple-touch-icon(?:-[0-9]+x[0-9]+)?\\.png).*)"],
};

Next.js Configuration:

const withNextIntl = createNextIntlPlugin();

/** @type {import('next').NextConfig} */
const nextConfig = {
  env: {
    BASE_URL: "https://www.example.com",
    images_domain: "https://images.example.com",
    api_domain: "https://api.example.com",
    mercureHubURL: "https://api.example.com/.well-known/mercure",
    topicURL: "https://api.example.com/api/games/",
    close_cookie_modal: "false",
    SITEMAP_SOURCE_DIR: "public/sitemap",
  },
  experimental: {
    serverActions: {
      allowedOrigins: ["example.com", "*.example.com", "localhost:3000"],
    },
    optimizePackageImports: [
      '@radix-ui/react-*', 'lucide-react', '@radix-ui/react-icons',
      'react-select', 'react-table', 'react-multi-date-picker',
      'react-day-picker', 'react-hook-form', '@hookform/*', 'date-fns',
      'lodash', 'axios', '@mantine/core', '@mantine/hooks'
    ],
    scrollRestoration: true,
  },
  images: {
    deviceSizes: [320, 420, 768, 1024, 1200],
    remotePatterns: [
      {
        protocol: "https",
        hostname: "images.example.com",
        pathname:'/**'
      },
    ],
    formats: ['image/avif', 'image/webp'],
    minimumCacheTTL: 60,
    dangerouslyAllowSVG: true,
    contentSecurityPolicy: "default-src 'self'; script-src 'none'; sandbox;",
  },
  serverExternalPackages: ['sharp'],
  webpack(config, { dev, isServer }) {
    // ... (webpack config is likely not the runtime issue, kept for completeness)
    return config;
  },
  compress: true,
  async headers() {
    return [
      {
        source: '/:all*(svg|jpg|png)',
        headers: [
          {
            key: 'Cache-Control',
            value: 'public, max-age=31536000, immutable',
          },
        ],
      },
    ];
  },
  reactStrictMode: true,
  compiler: {
    removeConsole: process.env.NODE_ENV !== 'development',
  },
  poweredByHeader: false,
  generateEtags: false,
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js'
      },
    },
  },
};

export default withNextIntl(nextConfig);

Deployment & PM2 Configuration:

Here is our CI/CD pipeline and PM2 configuration for additional context on our production environment.

on:
  push:
    branches: [ master ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js environment
        uses: actions/setup-node@v3
        with:
          node-version: '22'
      - name: Cache dependencies
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      - name: Install Dependencies
        run: npm ci --legacy-peer-deps
      - name: Build
        run: npm run build
        env:
          CI: false
      - name: Deploy to Server
        run: |
          rsync -avz --delete \
            --exclude=".git/" \
            --exclude="public/sitemap/" \
            --exclude="node_modules/" \
            ./ ${{ secrets.REMOTE_USER }}@${{ secrets.REMOTE_HOST }}:/path/to/app/
      - name: Install prod dependencies on server
        run: |
          ssh ${{ secrets.REMOTE_USER }}@${{ secrets.REMOTE_HOST }} \
            "cd /path/to/app && npm ci --omit=dev --legacy-peer-deps"
      - name: Reload PM2 App
        run: |
          ssh ${{ secrets.REMOTE_USER }}@${{ secrets.REMOTE_HOST }} \
          "cd /path/to/app && /home/user/.nvm/versions/node/v20.13.0/bin/pm2 startOrReload ecosystem.config.js --env production"
          ```

ecosystem.config.js : 

```module.exports = {
  apps : [{
    name   : "my-next-app",
    script : "./node_modules/.bin/next",
    args   : "start",
    interpreter: "/home/user/.nvm/versions/node/v20.13.0/bin/node",
    env_production: {
       NODE_ENV: "production"
    },
    node_args: "--unhandled-rejections=strict",
    log_date_format: "YYYY-MM-DD HH:mm:ss Z",
    max_memory_restart: "2G"
  }]
}

Partial package.json Dependencies:

We are using Next.js ^15.4.3 and React 19.1.0.

  "name": "my-next-app",
  "version": "2.0.0",
  "dependencies": {
    "@next/third-parties": "15.3.2",
    "next": "^15.4.3",
    "next-intl": "^4.0.0",
    "react": "19.1.0",
    "react-dom": "19.1.0",
    "sharp": "^0.34.2",
    "undici": "^6.21.3",
    "...": "..."
  },
  "devDependencies": {
    "eslint-config-next": "15.3.2",
    "typescript": "^5",
    "webpack": "^5.89.0",
    "...": "..."
  }
}

Analysis & Next Steps

Given the clinic.js report and the ResponseAborted errors, the event loop is clearly being blocked under load. The complexity of the middleware seems like the most probable cause.

Do you have any suggestions for how to best debug or profile the middleware itself to identify the exact bottleneck? For instance, is there a way to add more granular logging or performance marks to see which part (authentication, i18n, header application) is consuming the most time?

I am ready to run any further diagnostics or provide additional information that could help us resolve this. Thank you again for your assistance.

Best regards,

[sayou]

Thanks to everyone for responding and taking the time to help me solve the issue.

I made some code adjustments that improved things a bit, but after extensive research, it turned out that the main cause of the high load was bots performing a full site scan at high speed, especially the “Claude AI” bot.

The problem was solved by adding protection measures such as Cloudflare, which reduced the load by more than 90%.

I’m sharing this here in case it helps someone else.

[philasmar]

What are those Cloudflare measures?

[michaeltroya]

how did you identify the cause?

[cvienna]

Intro

I had similar issue with Next JS 16.1.6

The CPU usage on my dev server was exploding and constantly peaking. Making my computer almost overheat.

I managed to solve this very easily by adding a small argument --webpack to my dev command.

Solution

In package.json (under scripts).

Changed this:
"dev": "next dev"

to this:
"dev": "next dev --webpack"

Finally

I was earlier using turbopack, which I think is like default for Next JS... and that was burning up my computer.
I've run this for almost an hour without any issues - which might not seem like a lot, but better than earlier 😄

[IDJGILL]

Thank you soo much man, I'm using a mac m4 and It was burning like hell.

[sovetski]

Same problem here..

Disabling turbopack like suggested @cvienna and it looks ok now..

[devzerstudiosteam]

Same here

[fabri86]

Same here!
Using by default turbo, my laptop was literally taking off (CPU at 400%).
--webpack seems doing to work

[tobiaspickel]

Same for me disabling turbopack solved the issue here as well.

[devzerstudiosteam]

This happened on my next dev server, CPU% went to 600 on my Macbook M5 but after deleting all dependancies and removing .next folder and build again. issue was solved

[sovetski]

it is solved temporarily, after some time you will have the same problem again

[baalej]

I am also experiencing that issue.

It also got better after deleting .next and node_modules folders.

[sovetski]

This discussion is marked as "answered" but the answer is incorrect. The problem is real and still exists.

Related: #81161

People saying it is fixed in 16.3.0-canary.23, is it the case for everyone here?