> For the complete documentation index, see [llms.txt](https://megacrush.gitbook.io/megacrush-unity-assets/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-navmesh-baker/runtime-navmesh-baker-user-manual/package-elements/windows/bake-monitor.md).

# Bake Monitor

The **Bake Monitor** provides a live overview of the system during Play Mode.

> Open the Bake Monitor from Tools -> Runtime Navmesh Baker -> Window -> Bake Monitor

<figure><img src="/files/DSP5yrN7H0e6Ed2CjRxo" alt=""><figcaption></figcaption></figure>

### What it shows

* **Queued jobs and in-flight operations**
  * Current queue length, running async jobs, and skipped jobs
* **Per-surface status**
  * Registered surfaces, last bake result, last duration (ms)
  * Agent types baked for each surface
* **Aggregate metrics**
  * Update p95, Collect p95, Schedule p95 timings
* **Skipped counts and reasons**
  * “no-src” (no build sources found)
  * “outside-bounds” (region didn’t intersect surface)
  * “rebake-throttled” (profile rate limits)
* **Mode-aware view (new in 1.4.0)**
  * **Continuous AABB / Grid Cells**: live updates as bubbles/cells move
  * **One Shot**: shows one large enqueue at startup or when manually triggered, then remains idle unless a rebake is forced
* **Spawner Feedback (new in 1.4.0)**
  * Placement policy deferrals (“Require” spawns queued until bake complete) can be tracked alongside bake events

***

### When to use it

* **Profiling throughput** and locating bottlenecks in baking
* **Verifying grid rings / AABB updates** are enqueueing as expected
* **Confirming One Shot completion** before spawning AI
* **Spotting surfaces** that never contribute sources (high skipped counts)
* **Debugging deferred spawns** — ensure that “Require” policies resolve once the correct navmesh is baked

### What does **p95** mean in the Bake Monitor?

* **p95** = **95th percentile timing**
* It’s a common profiling metric that shows the worst-case performance experienced by \~95% of jobs (i.e. it ignores only the slowest 5%).
* This is more stable and useful than just showing **max** (which can be a single outlier), while still giving visibility into spikes.

The Bake Monitor reports **p95 timings** for the three main stages of the bake pipeline:

* **Update (p95)** — cost of updating surface state and enqueue logic
* **Collect (p95)** — time spent gathering geometry (`NavMeshBuildSource`) from registered surfaces
* **Schedule (p95)** — overhead of pushing jobs into Unity’s async NavMeshBuilder

***

#### Why it matters

* Helps you **spot systemic spikes** (e.g. if Collect p95 jumps when many colliders are spawned).
* Lets you **tune poll rates, rebake intervals, and concurrency** with a stable performance baseline.
* Useful for balancing CPU budget:
  * If **Update p95** is high → too many surfaces marked dirty too often
  * If **Collect p95** is high → surfaces have heavy geometry (colliders/meshes)
  * If **Schedule p95** is high → too many concurrent jobs or expensive tile builds