Audit log
An append-only record of who changed what
Every action taken in Manager is written to a log that cannot be edited or deleted, including by Manager. The chain is verified every night, and a break in it is detectable rather than theoretical.
Fourteen days, no card. Craft CMS 5 and later.
Shared responsibility needs a record
Several people share a maintenance rota. Somebody granted backups on a client site last month, somebody acknowledged a finding, somebody revoked a connector during a migration. Six weeks later nobody remembers which of them it was.
An audit log that the application can rewrite answers that question only until the answer becomes inconvenient. If a compromised account can tidy up after itself, the log tells you about honest mistakes and nothing else.
How the log is protected
-
The database refuses changes
A PostgreSQL trigger rejects any update, delete or truncate on the audit table. It holds even for the table owner, not only for the application role.
-
Privileges are revoked as well
The documented installation revokes update, delete and truncate from the application role outright, so there are two independent barriers rather than one.
-
Entries are hash-chained
Each entry carries the hash of the one before it and a sequence number, serialised by a database lock so two writers cannot fork the chain.
-
The chain is verified nightly
A scheduled command walks the chain at 03:00. A shorter but intact chain after a restore is expected; an altered chain with no restore is an incident.
What is recorded, and what is not
Who, what, when, from where
Actor, action, target, IP address, user agent, correlation ID, the before and after state, the outcome and the failure reason.
Acknowledgements are stored word for word
When somebody authorises backups on a site, the exact wording they agreed to is stored, so the record shows what they were told rather than only that they agreed.
Secrets throw rather than redact
A guard screens every payload and raises an error if something that looks like a credential reaches it. Silently redacting would let a mistake continue unnoticed for years.
Enrolment codes and hashes are never written
The log records that a code was issued and consumed, never the code.
Deleted backups leave their row behind
Pruning destroys the artefact and its keys. The audit entry survives, so the record still shows that the backup existed and when it went.
The outcome
You can answer who granted what, on which site, and when, six weeks after the fact, and so can a client asking the same question.
Read how it works
The documentation lives in the public repository, next to the code it describes, and every page carries a link to edit it.
Related
-
Encrypted Craft CMS database backups
Daily or weekly database backups without handing over database credentials. Encrypted on your server before they leave it.
-
Alerts for the issues that need a person
Four events, by email or webhook, filtered by severity. Queued, so a slow endpoint never delays a site report.
-
Find the Craft sites that need attention first
Eighteen rules run against every report. Findings open with a severity, and close themselves when the site is fixed.
See your whole fleet in about ten minutes
Add a site, install the connector with Composer, paste the one-time code. The first report arrives on the next run. Fourteen days free, no card, and nothing on your sites changes.
Craft CMS 5 and later. Read-only by default. AGPL-3.0-or-later.