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,

[icyJoseph]

Hi,

Have you tried to run these in a newer Node.js version? There's always a lot of fixes to the runtime itself that one should benchmark against - specially when it comes to native fetch - if its possible to use a later runtime, it is worth trying - though, even in 21-22 there seems to be still some memory leaks related to abort signal and fetch.