Stack Trace Capture Settings

Three settings govern what a stack trace contains. They interact, so it is worth seeing them together rather than one at a time.

Where to find it

Architect Panel → Configuration:

Site Settings — Capture Stack Trace, Include Arguments in Stacktrace, Stack Frame Limit

Architect Panel → Activity:

Error Log — the result

The three settings

Capture Stack Trace — whether a trace is recorded at all. Everything else depends on this.
Include Arguments in Stacktrace — whether the values passed to each frame are recorded.
Stack Frame Limit — how many frames are kept.

How they combine

The limit multiplies the effect of arguments. A four-frame trace with arguments records the values passed to four calls; a fifty-frame trace with arguments records fifty. The storage and the exposure both scale with the product of the two, not with either alone.

That is why a large limit and arguments together is the combination to avoid, and why raising one should prompt a look at the other.

Sensible combinations

Production — capture on, arguments off, a small limit. Enough to see the route without accumulating data.
Development — capture on, arguments on, a larger limit. Maximum information, no real data at risk.
Production, investigating — arguments temporarily on, limit unchanged, both reverted afterwards.

Change one thing at a time

When a trace is not telling you enough, raise the limit first. It is the cheaper of the two adjustments and it frequently resolves the problem on its own, because the missing context is usually a caller further out rather than a value.

Reach for arguments only when the route is clear and the failing value is not.

Verify after cloning an environment

These settings travel with a configuration copy. A production instance built from a development snapshot will carry development's settings — arguments on, a generous limit — and nothing will draw attention to it.

Add it to whatever checklist you use when standing up an environment.

They apply to errors, not to normal operation

Nothing here is recorded during ordinary use; these settings only take effect when an error occurs. The performance question is therefore about how many errors you have rather than how much traffic — another reason a rising error rate deserves attention.

Worked example

A team runs production with capture on, arguments off and a limit of four. An obscure failure produces a trace that stops short of anything meaningful, so they raise the limit to twelve for a week. The extra frames show the call originating in a scheduled task, which is enough — arguments are never needed, and the limit goes back to four.

Recommendations

Capture on, arguments off, small limit in production.
Raise the limit before enabling arguments.
Never combine a large limit with arguments on live data.
Check these settings whenever you clone an environment.