You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our first production Git deployment upgrading from Sentry 10 to 11 stopped at Creating an optimized production build and was terminated with BUILD_EXCEEDED_MAXIMUM_TIME (45 minutes). The preceding build, also without cache, compiled in 2.2 minutes. There is no explicit Vercel OOM error.
Isolation and mitigation
A clean local build with 4-CPU affinity, an 8-GB memory cgroup, no swap, and production environment completed with only buildTimeInstrumentation: false changed (98-second compilation).
We inspected maybeAddOrchestrionRule in constructTurbopackConfig: the *.{js,mjs,cjs} rule has condition node. An experimental local patch added a node_modules path condition derived from getSentryInstrumentations() module names. A subsequent clean source build on Vercel compiled in 107 seconds and completed in 4m15s; AI SDK/OpenAI/Anthropic registration calls were present in generated output. This suggests the broad loader rule may contribute, but we have not profiled the precise bottleneck or produced a public minimal reproduction.
We are removing that custom patch and using the supported buildTimeInstrumentation: false option while investigating.
Questions
Is excessive Turbopack loader work with the default Orchestrion rule a known v11 issue? Is package-level filtering supported or planned?
Which automatic server traces are lost with buildTimeInstrumentation: false on Vercel, particularly bundled AI SDK 7, OpenAI and Anthropic SDKs, and database clients? Which still work through runtime channels or Next.js instrumentation?
Is there a supported selective option to preserve these integrations without passing every server JavaScript module through the loader?
What profiling output or minimal reproduction would be most useful?
Error reporting, source map upload and explicit application spans remain configured. We are not claiming this mitigation preserves all automatic trace coverage.
We've seen the same issue, came up on our main branch but not on alt branches. We're using CircleCI and disabling buildTimeInstrumentation stopped the build hanging. I can't give much more context on why the build hangs due to how CircleCI reports the failure as an infrastructure failure and doesn't give us any resource consumption metrics, but that itself could be a clue, I have never seen one of these specific failures before (been building Next.js 11->16 on CircleCI for 4 years)
We'll release a new version today (you'll be notified in this issue once it is out) which will contain the fix, please feel free to ping me if your issue persists!
Activity
linear-code commentedon Sep 25, 2026
JS-3823
chargome commentedon Sep 28, 2026
Hey @ricardostmalo thanks for reaching out!
This is the first issue commenting on turbopack build timeouts, let me investigate and get back to you.
harry-gocity commentedon Sep 28, 2026
We've seen the same issue, came up on our main branch but not on alt branches. We're using CircleCI and disabling
buildTimeInstrumentationstopped the build hanging. I can't give much more context on why the build hangs due to how CircleCI reports the failure as an infrastructure failure and doesn't give us any resource consumption metrics, but that itself could be a clue, I have never seen one of these specific failures before (been building Next.js 11->16 on CircleCI for 4 years)fix(nextjs): Limit Turbopack orchestrion loader to instrumented packa…
chargome commentedon Sep 28, 2026
We'll release a new version today (you'll be notified in this issue once it is out) which will contain the fix, please feel free to ping me if your issue persists!
And thanks again for reporting this right away 🙏
harry-gocity commentedon Sep 28, 2026
@chargome Always appreciate the quick turnaround on reported issues 🫡 thank you!
github-actions commentedon Sep 28, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #24792, which was included in the 11.1.0 release.