System health

The System health page lets a platform administrator verify that the event log is a complete and faithful record of the database state.

What verification checks

Belsimple is event-sourced: every write that changes the state of a tenant’s data (a task, a classification, a time entry, a user, …) also records an event describing the change. Verification replays every recorded event against an empty in-memory state, then compares that reconstructed state to what is actually stored in the database.

If the two disagree, you get a list of mismatches — for example:

• Task <id> title: db="Renamed" replayed="Old name"
• TimeEntry <id> exists in DB but not in events
• Classification <id> exists in events but not in DB

A clean run means:

• Every live database row has a corresponding creation event.
• Every event translates to a consistent final state.
• Nothing has been mutated outside the event system.

Seed users and platform admins created outside the event system are intentionally excluded from the check.

When to run it

• After a production incident or a manual database edit.
• Before and after a migration that touches event-sourced tables.
• Periodically as a sanity check on data integrity.

What it costs

Verification fetches every event and every row from the event-sourced tables. On a small or medium database it completes in a few seconds; on a large database it can take tens of seconds. The request blocks a single request worker while it runs — don’t run it during a demand spike.

Interpreting failures

If verification reports mismatches:

1. Do not dismiss them. Each mismatch is a sign that the database and the event log have drifted.
2. Export the list and share it with engineering.
3. Investigate the specific entity IDs. The audit log may help correlate the mismatch with a recent operation.
4. If a recent code change is suspected, roll back and re-run verification.