Quick answer: Use the Profiler's Physics module to isolate physics time from rendering and scripts, find the expensive collider configurations or contact counts, and reduce them or adjust the fixed timestep.

A frame spike is not always your scripts; sometimes the physics engine is the one stalling. The Profiler can split physics out from rendering and game logic, and once you know the cost is in the simulation, you go looking at colliders and contacts, not your code.

How to find it

1. Isolate physics in the Profiler

Enable the Physics module and compare its time against CPU script time and rendering on the spiking frame. If the physics track owns the spike, the problem is in the simulation, not your Update.

2. Find the contact and rigidbody cost

Check active rigidbody and contact counts. A pile of dynamic bodies, mesh colliders, or many simultaneous contacts makes a single physics step expensive.

3. Simplify the colliders

Replace mesh colliders with primitives, sleep or pool inactive bodies, and use layer-based collision filtering so the solver does far less work per step.

4. Confirm with FixedUpdate timing

Time your FixedUpdate and the physics step directly, and check whether multiple physics substeps run per frame at low frame rates. Tuning the fixed timestep can stop physics from compounding the spike.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Unity error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

A crash you can name from its stack trace is a crash you can usually fix in minutes.