Security, Abuse & Privacy

Audit Log

Definition

An audit log, sometimes called an audit trail, records administrative actions rather than traffic. Each entry pins down five things: the actor, the action, the object it was performed on, the time, and the context the request came from, usually an IP address and a user agent or token name. Typical entries for a hosting account are a sign-in, a failed sign-in, a file published or replaced, a file deleted, a link password set or removed, a custom domain added, an API token created and an invitation accepted. The distinguishing property is that it is append-only — entries are written once and never edited, because a record that the people being recorded can amend proves nothing. It differs from an access log in who it is about: the access log lists visitors fetching files, the audit log lists the account holders changing them.

Why It Matters

The moment it earns its keep is always the same: something changed and nobody admits to it. A page shows last quarter's pricing, a shared folder has gone, a download that worked on Friday returns a password prompt. Without a trail the conversation becomes guesswork among three people with the same login; with one it is a line saying which account replaced which file at 16:42 on Tuesday. It matters more the more people have access — a five-person team sharing one password has no audit trail worth the name, whatever the system records. Security questionnaires ask for it, incident reviews depend on it, and after a compromise it is the only way to work out what the intruder actually touched.

How It Works

Entries are written by the application as each action completes, to a store the account holder can read but not modify. Retention is commonly 90 days on lower tiers and a year or more on business plans, and mature systems offer export so the log can be shipped into whatever the organisation already searches. Reading one well means filtering rather than scrolling: by actor when a person has left, by object when one file is the question, by action when you want every deletion in a month. Two patterns are worth alerting on — a run of failed sign-ins followed by a success, and an API token created shortly before a burst of activity — because both are what an account takeover looks like from the inside. The log is also personal data about staff, so it inherits a retention period rather than living forever by default.

Real-World Example

A three-person studio finds that the brochure at studio-brochure.99helpers.site has reverted to an older design overnight. The account history shows a rollback performed at 23:10 by the designer, who had been tidying version history from a phone and restored the wrong entry. One-click rollback on 99helpers puts the current version back in seconds, and the argument that would have filled a morning lasts about ninety seconds instead. The follow-up is duller and more useful: separate logins each, so the next entry names a person rather than a shared account.

Common Mistakes

  • Sharing one login across a team — every entry then names the same account and the trail explains nothing
  • Keeping the log where an administrator can edit it — a record that can be rewritten by the people it records is not evidence
  • Only looking after an incident — a weekly glance at token creations and failed sign-ins catches the problem while it is still small

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →