System logs

System logs capture the platform’s operational events — the technical record of what the system itself is doing. Where the audit trail records business actions for compliance, system logs record operational events for troubleshooting and observability.

The reason a regulated platform separates operational logs from the compliance audit trail is that they serve different questions and different people. When an administrator is diagnosing why a scheduled export failed at 2am, they need technical detail — levels, errors, stack context — that would be noise in an audit trail, and that trail in turn must stay focused on business actions to remain useful as evidence. Keeping the two distinct means each stays fit for its purpose: system logs for keeping the platform healthy, the audit trail for proving what was done to the records.

What the logs show

System logs record events at different levels — from routine information through warnings to errors — so you can see both that the platform is operating normally and where something has gone wrong. You can filter by level to focus on what matters: surface only errors when investigating a problem, or review the broader picture when checking overall health.

Audit trail versus system logs

It’s worth keeping the two straight. The audit trail answers “who changed this record, and when?” — it’s compliance evidence. System logs answer “is the platform working, and what happened technically?” — they’re operational diagnostics. Both matter, but for different reasons, and they’re reviewed in different places.

Observability for a regulated system

For a platform that holds regulated records, operational health isn’t incidental — availability and correct operation are themselves part of a dependable system. System logs give administrators the visibility to catch and diagnose issues, complementing the scheduled jobs view and rounding out the picture of how the system is running.