Stack Frame Limits
The Stack Frame Limit is the maximum number of frames recorded with an error. It ships small, and that is usually correct.
Where to find it
Architect Panel → Configuration:
- Site Settings — Stack Frame Limit
Architect Panel → Activity:
- Error Log — where the recorded frames appear
What a frame is
One step in the chain of calls. The first frame is where the error occurred, the second is what called that, and so on outwards. A limit of four keeps the four nearest and discards the rest.
Why nearest-first is the right end to keep
The frames closest to the failure are almost always the informative ones. The outer frames tend to be the same general machinery on every request, so keeping them costs storage and tells you little.
This is also why a small limit is a reasonable default rather than a compromise — it keeps the part you would read.
When to raise it
Raise it when traces are consistently stopping just short of something useful — typically when the error occurs in shared code reached from many places, and the four nearest frames are identical every time.
Go up in steps. Doubling is usually enough, and going straight to a very large number produces traces nobody reads and, with arguments enabled, a great deal of captured data.
What it costs
Storage per error, multiplied by your error rate. On its own that is minor. Combined with argument capture it is not, because each additional frame brings the values passed to another call.
If you are raising the limit on a system with arguments enabled, consider turning arguments off first.
It does not change what failed
Worth stating because it catches people out: raising the limit does not produce more errors or different ones, and lowering it does not hide problems. It only changes how much of the route is described. If a trace is unhelpful, the limit is one possible reason — the error message and the surrounding log entries are others.
Put it back afterwards
A limit raised for one investigation tends to stay raised. Note the original value when you change it, and restore it when you are done — otherwise you accumulate a setting nobody remembers choosing.
Worked example
A platform runs with a limit of four. A recurring error in a shared validation routine produces four identical frames every time, saying only that validation failed somewhere. The limit goes to eight; the extra frames show two distinct callers, one of which is a form nobody had associated with the problem. The fix takes an hour, and the limit returns to four the same day.
Recommendations
- Leave it small by default.
- Raise in steps, and only when traces stop short.
- Turn arguments off before raising it on a live system.
- Record the original value and restore it afterwards.