A host application using Module Federation goes into production, and users start seeing a blank panel where a remote-loaded micro-frontend should render, with a network error for remoteEntry.js in the console. What are the likely causes, and how should the host be built to degrade gracefully?

## What the blank panel is telling you A blank panel accompanied by a network error for `remoteEntry.js` is the single most common production failure mode in Module Federation systems, and it almost always traces back to one of a small set of causes, each with a distinct signature once you know what to look for. ## The remote is unreachable The most frequent cause is simply that the remote is unreachable: - its CDN path changed, - a deployment removed the old version's assets before the host's cached page finished loading it, - a CORS policy on the remote's hosting doesn't allow the host's origin to fetch the script, - or the remote's own deploy is mid-rollout and briefly 404s. Because the host only discovers this at the moment a user's browser actually tries to `import()` the remote, not at the host's own build or deploy time, this class of failure is invisible to the host team's CI and only surfaces live, often intermittently, which is what makes it feel like 'it worked yesterday.' ## A shared-dependency version conflict A second, subtler cause is a shared-dependency version conflict: if `react` or another `singleton: true` shared package can't be resolved to a mutually compatible version between host and remote, Webpack's runtime can throw during the remote's `init()` call rather than rendering — the console error here typically mentions 'Shared module is not available for eager consumption' or an unsatisfied version range, distinct from a plain network failure but producing the same visible symptom of nothing rendering. Notably, this can happen even when remoteEntry.js itself loads with a clean 200 status, since the failure is in a later initialization step, not the fetch — a detail that quickly distinguishes it from the pure network-reachability cause during triage. ## A bug inside the remote itself A third cause is a runtime error inside the remote's own code once it does load, a genuine bug in that team's bundle, which, because the remote and host are compiled independently, can throw in a way the host's error boundaries were not written to expect, sometimes crashing more of the page than just the federated panel if the mount point isn't isolated. ## Building the host to degrade gracefully Building a host to degrade gracefully against this class of failure means treating every federated import as an operation that can fail, not as a guaranteed synchronous render. Concretely: - Every federated mount point should be wrapped in its own **error boundary**, scoped tightly around just that remote's rendered output, so a crash in the checkout remote shows a fallback only in the checkout panel rather than taking down the whole shell page. - The `import()` call itself should be wrapped with a **timeout** and explicit catch — a remote that hangs rather than errors, for example a slow or stalled network request, will otherwise leave the user staring at a loading spinner indefinitely, so a reasonable pattern is to race the import against a timeout and show a 'this section is temporarily unavailable' fallback if it doesn't resolve. - **Retrying** with a fresh cache-busted URL on failure can recover from transient CDN or deploy-window issues automatically. - Because these failures are runtime and often user-specific, such as a particular browser's cached remoteEntry.js version or a particular CDN edge node having stale content, production observability needs to specifically capture and alert on federation-boundary errors — plain frontend error tracking often buckets all of these under a generic chunk-load-error category unless the host explicitly tags which remote and which shared-dependency negotiation was involved, making root-causing painful without that extra instrumentation. ## A worked deploy-window scenario A concrete worked scenario makes the failure modes tangible: suppose a payments team redeploys their checkout remote and, for two minutes during the CDN's cache invalidation window, some edge nodes still serve the old remoteEntry.js referencing chunk hashes that the origin has already removed, while other edge nodes serve the new one. Users hitting the stale edge see a 404 for a specific chunk file mid-render, not for remoteEntry.js itself, producing an error that looks superficially like a remote-internal bug but is actually a deploy-propagation timing issue; teams that have seen this before recognize the signature, retry after a short delay, and often add a brief overlap window where both old and new chunk hashes remain live on the CDN specifically to eliminate this race. ## The architectural lesson At an architectural level, the deeper lesson these failures teach is that Module Federation converts what used to be a single application's internal wiring into a distributed system with its own partial-failure semantics — the same category of problem as a service calling a downstream microservice over HTTP, just happening inside the browser instead of between servers. Teams that treat federated remotes with the same rigor as any other network dependency, including health checks before promoting a new remote version, staged rollouts, error-boundary isolation, and explicit fallback UX, see this class of incident become rare and low-blast-radius; teams that treat `import('remote/Module')` as equivalent to a plain local import get paged the first time a remote's CDN has a bad five minutes.