iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Angular’s NG0506 warning means that, during client-side hydration, ApplicationRef.isStable did not emit true within 10 seconds. It tells you the app has not reported stability; it does not identify the task causing the delay. Find the pending work with Angular’s stability diagnostics, then decide whether it should be stopped, moved until after stability, or explicitly tracked.
What NG0506 means and why it matters
Angular waits for the application to report stability before proceeding with hydration-related work. Its hydration guide says that hydration and post-hydration processes occur once the application has reported stability. In the browser, this includes starting cleanup of DOM nodes that hydration did not claim. On the server, stability also matters because Angular uses it during SSR serialization.
The warning is not proof that hydration has failed or that one specific request is responsible. It indicates that the application remained unstable past Angular’s documented 10-second threshold. Use it as a prompt to locate the work keeping stability pending, and verify the effect of any fix in your app.
First identify your Angular version and change-detection mode
Check the project’s Angular version and whether it is configured for Zone.js or zoneless change detection before applying a fix. The current Angular guide says zoneless is the default in Angular v21 and later; Angular v20 projects can opt in explicitly. A project may still configure Zone.js, so the version alone does not establish the mode. See Angular’s versioned zoneless guide.
#1 Best Overall
| Area | Zone.js | Zoneless |
|---|---|---|
| Common leads | Timers, pending requests, repeated animation-frame work, and third-party asynchronous tasks. | Repeating effects or signal changes, pending requests, and asynchronous work that should be tracked. |
| Diagnostics | Angular stability debugging; optionally use Zone.js task tracking temporarily for macrotask details. | Inspect effects and pending task tracking; do not use NgZone stability observables as the stability signal. |
| SSR task tracking | Zone.js contributes task tracking. | Use PendingTasks when work must finish before serialization. |
Find the work that is delaying stability
- Confirm the context. Verify that client hydration is enabled and that NG0506 appears in the browser during hydration. Angular’s NG0506 reference scopes the warning to this situation.
- Enable Angular’s diagnostic logging in development. Add
provideStabilityDebugging()to the application providers and reproduce the warning. Angular documents this utility for reporting task information when stability takes longer than expected. It is stable since Angular v21.1; check its API documentation for availability in your installed version. - For Zone.js, inspect macrotask creation stacks when needed. Temporarily import
zone.js/plugins/task-trackingand reproduce the issue. Combined with stability debugging, task tracking can provide more detail about macrotasks and where they were created. Angular cautions that these debugging utilities are not stripped from production bundles, so remove them after diagnosis. - Check the usual sources. Look for initialization-time
setIntervalorsetTimeout, repeatedrequestAnimationFramecalls, pending HTTP requests, unresolved asynchronous work, and third-party tasks. In zoneless code, also inspect effects that repeatedly change signals and may create a loop. - Retest hydration after changing the task. Confirm that the application stabilizes when expected and that hydration and post-hydration cleanup behave correctly.
Fix recurring work in a Zone.js app
Move recurring tasks out of Angular’s zone when appropriate
A recurring task started during application initialization can prevent the app from becoming stable. If the task does not need to trigger Angular change detection on every run, schedule it outside Angular’s zone. Angular’s NG0506 guidance recommends this approach for recurring work that must begin during initialization. Do not move a task outside the zone automatically: first determine whether its updates need to participate in change detection.
Start work after the first stable emission when timing allows
If a recurring task only needs to start after the app stabilizes, wait for the first truthy emission from ApplicationRef.isStable before starting it. The observable runs outside Angular’s zone. Consequently, changing an ordinary component field in its subscription does not automatically refresh the view in a Zone.js app; re-enter the zone or trigger change detection explicitly if the subscription updates UI state. Angular documents these behaviors in the ApplicationRef API and NgZone API.
Track required asynchronous work in a zoneless app
In zoneless applications, do not use NgZone.onMicrotaskEmpty, onUnstable, onStable, or isStable to infer application stability: those observables do not emit under zoneless change detection, and NgZone.isStable is always true. For code that needs to wait for a render, Angular recommends render hooks such as afterNextRender or afterEveryRender instead of using zone events indirectly. See the NgZone API.
For asynchronous work that must finish before SSR serialization, use PendingTasks. Its add() method returns a cleanup function; call that function when the work finishes, including in a finally path so failures do not leave a task registered indefinitely. The API also offers run() to track a promise-returning function. Angular’s zoneless guide notes that it already accounts for some work, including router navigation and incomplete HttpClient requests. Use pendingUntilEvent for observable work where appropriate. Details are in the zoneless guide.
Rank #3
When delayed stability is intentional
Some applications may have work that keeps the app unstable for more than 10 seconds by design. Angular says the warning may be ignored in that case, but the choice should be deliberate: check that hydration and its cleanup behave as expected in the specific application rather than assuming the warning is harmless. If the task is not needed before stability, defer it; if it is required for SSR serialization in a zoneless app, track its lifecycle with PendingTasks.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
