Failed to compile: distinguishing critical build errors from noisy warnings in Next.js alerting

Gate the alert on the exit code, not the string

The reliable discriminator between a critical Next.js build failure and a noisy warning is the next build process exit code — not the Failed to compile text. A failed compilation exits non-zero; deprecation notices, experimental-feature banners, and bundle-size warnings print to the same stream but exit 0 unless you have explicitly configured them to fail. CI runners already capture that exit code, so the alert trigger should be 'the build step failed', and log text should only ever be payload attached to the alert, never the trigger itself.

Established behavior vs. version-dependent details

Well-established: a fatal compilation error (syntax error, unresolved import, TypeScript error when type checking is enabled) makes next build exit non-zero, and warnings do not fail the build by default. This holds across the webpack and Turbopack eras because it is CLI contract, not formatting.

Version-dependent, so verify against your pinned release: the exact wording and placement of Failed to compile, and whether lint runs inside next build at all — lint-during-build behavior changed around the Next.js 15/16 releases (next lint was deprecated), so a pattern tuned for one major may match nothing in another. I am not aware of a maintained plugin that attaches severity metadata to build output; treat that open question as unresolved rather than assuming one exists.

Why string matching fails in both directions

• Under-matching: ANSI color codes, redirection, and wrapping loggers break literal matches. Worse, some real failures — OOM kills, a missing next binary, a thrown config error — exit non-zero without ever printing Failed to compile.
• Over-matching: the phrase can appear in captured dev-overlay output or dependency logs that are not the build verdict.
• Silent config drift: typescript.ignoreBuildErrors and eslint.ignoreDuringBuilds can downgrade would-be failures into warnings, so a string-based alert under-fires while the build 'succeeds'.

Steps for this case

1. Trigger on exit code. In bash, beware the pipe: next build | tee build.log returns tee's status unless you set pipefail:

   set -euo pipefail
   next build | tee build.log

   In a Node wrapper, check the status from spawnSync and re-exit non-zero so the CI runner sees the failure. Any custom script around next build must propagate that status.

2. Classify with separate steps, not severity parsing. Run tsc --noEmit and ESLint as their own CI steps before next build. Each step's failure maps to a distinct alert channel; warnings stay visible in the lint step without paging anyone. Do not flip all warnings to error severity to make logs match exit codes — that recreates the fatigue you are trying to remove.
3. Attach text as payload. If the alert needs the error message, capture the output tail and strip ANSI codes before storing. If a log aggregator must match something, have the build step emit its own structured marker line (for example, JSON containing the exit status) — you control that format, so it survives Next.js minor releases.
4. Verify once per version bump. Introduce a deliberate syntax error and confirm a non-zero status (npx next build; echo $?), then a known deprecation warning and confirm 0. Two minutes of checking catches formatting drift immediately.

One detail that changes the recommendation

If your alerts fire from a log aggregator that never sees the CI runner's exit code, the approach above needs adjusting — tell me which aggregator you use and where the build runs. In that case the right fix is emitting your own structured success/failure marker from the build step, not parsing Next.js prose at all.