Error Logging Modes
Error Logging Mode decides where the platform records errors. It is one setting with four values and it is worth choosing deliberately.
Where to find it
Architect Panel → Configuration:
- Site Settings — Error Logging Mode, and the stack trace settings alongside it
Architect Panel → Activity:
- Error Log — errors recorded to the database
The four modes
- Database — errors are written to the platform's own error log and read from the Architect Panel.
- PHP error log — errors go to the server's error log, alongside everything else the server records.
- Both — written to each.
- None — errors are not recorded at all.
Which to choose
Database is the right default for most installations. Errors are searchable and filterable in the panel, they are visible to administrators who have no server access, and they are included in the database backup.
Both suits installations with a server team who want errors in their existing server monitoring as well.
PHP error log alone makes sense where an administrator should not see application errors, or where the volume is high enough that you would rather not carry it in the database.
Never choose None on a live system
It is available for a reason — a short-lived load test, a diagnostic exercise — but a production system that records no errors cannot be supported. Problems become anecdotes, intermittent faults become unprovable, and the first real evidence of a failure is a user describing it from memory.
If volume is the concern, address the errors rather than the recording.
Output Errors to Browser must stay off
There is a separate setting that sends errors to the browser. It exists for local development and must be disabled on any production site.
The reason is specific rather than general caution: an error and its stack trace can contain sensitive data — values being processed at the time, connection details, occasionally credentials. Displaying that to whoever triggered the error hands it to them, and the people most likely to trigger unusual errors are the people probing your site.
Check this setting after any configuration restore or environment clone. It is the classic thing to have been enabled on the development instance and copied.
Pretty errors are development only
The same reasoning applies to enriched error display. Anything that makes an error more readable makes it more readable to everybody.
Review the log, do not merely collect it
An error log nobody reads is storage. Make it a routine — after every deployment, and once a week otherwise. What you are looking for is a new error type or a change in rate, not a zero count.
Worked example
An installation runs in database mode. After a release, the weekly check shows a new error type appearing about forty times a day, all from one integration endpoint. It had been failing silently for six days because the integration retried and eventually succeeded. It is fixed before anybody notices a delay — which is only possible because the errors were being recorded and read.
Recommendations
- Use database mode unless you have a reason not to.
- Never run production with recording disabled.
- Verify browser output is off after any environment clone.
- Read the log weekly, looking for new types rather than totals.