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.