How many frames is too many? How few is too few? Stack frame limits are a balance — too low and you miss the cause; too high and traces become unreadable and storage-expensive.
Default Limits
- Production default: 50 frames.
- Truncation indicator: If more frames exist, the trace shows “… 17 more frames omitted”.
- Per-frame size cap: Each frame's argument dump capped at 4KB.
- Total size cap: Trace truncated if it exceeds 64KB total.
How Many Frames Do You Really Need?
- The most useful frames are usually the bottom 5-10 (where the exception originated) and the top 2-3 (the entry point and controller).
- Middle frames are mostly framework plumbing.
- If you skip vendor/framework frames, your own code is typically 5-15 frames — perfectly readable.
When to Raise the Limit
- Deeply recursive code where the recursion path is the bug.
- Stack overflows — you need to see the full chain to find the cycle.
- Multi-tier framework debugging where the framework's internal path matters.
When to Lower the Limit
- Storage cost is squeezing.
- Most errors are simple and don't need deep traces.
- You consistently skip past the deep frames anyway.
Worked Examples
- API service: 30 frames with vendor/framework skip — typically captures 8-12 own-code frames. Clean and focused.
- Recursive workflow: Raise to 200 for one workflow type that has up to 50 levels of recursion.
- Storage tight: Lower to 20 frames + 32KB total cap. Loses some detail on deep paths but saves significant space.