Audit log
Every action that reads or changes user data, and most configuration changes, is written to Restow’s audit log, through the web interface, the integration API, or an admin-consent flow. This is not optional logging: the database itself rejects UPDATE/DELETE on the audit table.
What’s recorded
Section titled “What’s recorded”Each entry carries who (a user, an API key, or “system”), when, what (an action, e.g. “Restore requested” or “Admin consent granted”), for whom if it was done on someone else’s behalf (impersonation), the target (a mailbox, a source, a webhook, and so on), the tenant, and the IP address the request came from.
Categories span sign-in, sources, directory sync, backup, restore, verification, storage, settings, tenants and members, API keys, webhooks, licensing, the archive, endpoint backup, mail import and export, updates and the operator notice.
Tamper evidence
Section titled “Tamper evidence”Entries are chained per tenant (each entry links to the hash of the one before it) and sealed with a daily anchor, so a change made after the fact is detectable: it breaks the link to the next entry, or no longer matches the day’s anchor. In the viewer, Verify now re-checks the whole chain and reports exactly where a break is, if there is one, and since when entries can no longer be vouched for.
Finding entries
Section titled “Finding entries”In the viewer (Business and Service Provider), filter by tenant (provider admins can choose “All tenants” or the installation’s own entries), action or action category, actor (email, name or user ID), target, and a date range. Every entry that reads user or backup data on someone’s behalf (an admin opening another user’s mailbox in Restore, a report generated across a tenant, a permission check) appears here too, not just the actions that change something.