Error Logging

The platform's error logging can run in several modes depending on how much detail you need vs how much you can afford to capture. Higher-detail modes give better post-mortems but use more storage and slow request processing slightly.

Available Modes

• Disabled: Errors not logged at all. Never use in production.
• Counts only: Each error type incremented in a counter; no per-event details. Cheapest, useful for high-throughput environments where individual errors are noise.
• Standard: Per-event log with timestamp, error class, message, request URL, user, minimal context. Default and sensible.
• Verbose: Per-event log plus full stack trace, function arguments, request body, session, environment. Use during incidents.
• Sampled: Standard for most events, verbose for a configurable percentage (e.g. 1%). Best of both worlds for very high traffic.

Choosing a Mode

• Dev: Verbose — you want everything.
• Staging: Verbose for the full test cycle.
• Low-traffic production: Standard.
• High-traffic production: Sampled (e.g. 1% verbose) to keep cost manageable.
• During incident: Flip to Verbose for 24-48 hours, capture the data needed, flip back.

Worked Examples

• Small SaaS: Standard mode everywhere. ~100 errors/day; full per-event detail is cheap.
• Marketplace at scale: Sampled mode in production. 100k errors/day total; 1% verbose still gives 1k full traces — plenty.
• Incident response: A critical bug causes 10k errors/hour. Flip to verbose for 1 hour, capture full traces, flip back.
• Compliance environment: Standard mode plus forwarded to external SIEM for long-term retention.

Warning: Verbose mode captures request bodies and session contents. If you log PII, ensure the logs are encrypted at rest and access-controlled.

Stack traces are the breadcrumbs that lead from a thrown exception back to the line of code that caused it — and through every caller in between. They're the single most useful piece of debugging information when something goes wrong.

What's Captured

• Exception class and message: the type of error and human-readable text.
• Frame stack: the chain of function calls from where the error was thrown back up through the entry point.
• For each frame: file path, line number, function name.
• Optionally: function arguments at each frame, local variables.
• Context: request URL, user ID, IP, request body summary.

When Traces Are Captured

• Uncaught exceptions always produce a trace.
• Caught exceptions can optionally call $AM->logException($e) to record without re-throwing.
• Manual capture points: $AM->logTrace('reached suspicious branch') records a non-error trace.

Performance Cost

Capturing a stack trace is cheap — measured in microseconds. The expensive part is including arguments (next article). Standard stack-trace-only capture is essentially free.

Worked Examples

• Null pointer in checkout: Trace shows the exception originated 3 frames deep in cart-helper.php, called from checkout.php, called from the controller. Bug is in cart-helper.
• SQL error in API: Trace shows the bad query was built inside query-builder.php with caller-provided invalid filter. Adjust the input validation.
• Performance regression: Manual trace at known slow point reveals the new caller path that bypassed the cache.
• Cross-service issue: Stack trace plus request URL identifies the upstream consumer that's hitting a now-deprecated endpoint.

Arguments to each function call massively improve diagnostic value — you see not just where the code went but what data it was working with. But they cost more to capture and may contain sensitive information. This article covers the tradeoffs and configuration.

What Gets Included

• Scalar arguments (numbers, strings, booleans) shown inline.
• Arrays and objects summarised — type and key count, e.g. array(7).
• Optionally a depth-limited dump of the values for short objects.
• Resources (DB connections, file handles) shown as type + ID.

Privacy and Redaction

Argument capture risks logging PII or secrets. The platform redacts known-sensitive parameter names automatically:

• password, password_hash, secret, api_key, token, card_number, cvv.
• Anything matching a configurable regex (e.g. /.*_secret$/).
• Field-level redaction via per-datastore declarations.

Performance Cost

Capturing arguments doubles or triples the trace generation cost (still microseconds, but it adds up at scale). Don't enable arguments in counts-only mode; do enable in incident-response mode.

Configuration

1. Open Site Settings → Logs → Error Logging → Stack Traces.
2. Toggle Include arguments in stack traces.
3. Set argument-value depth (default 2 — dumps 2 levels into nested structures).
4. Tune the redaction list.
5. Save.

Worked Examples

• Standard production: Arguments disabled. Stack traces alone normally tell us enough.
• Live debugging session: Arguments enabled for 2 hours during an incident; reverted after.
• Sensitive workflow: Arguments disabled globally but a specific function annotated to capture them despite the rule.
• Heavy redaction: Regex pattern added to redact any field with “_pii_” or “national_id” in its name.