Audit log

The audit log is your team’s record of every meaningful action: who did it, which site or environment it touched, and when. It’s there for accountability, incident review, and the compliance and white-label obligations that come with running sites for other people. Nothing destructive or privileged happens on managed.dev without leaving an entry.

The log is scoped to your team. Members see entries for the projects they have access to; owner and unscoped admin see everything across the team.

What’s captured

Every state-changing action is recorded — both from the dashboard and from the public API. That includes, among others:

• Membership and access — invites sent and accepted, role changes, members removed, ownership transfers.
• Sites and environments — sites created, migrated, or deleted; environments provisioned, reset, or torn down.
• Deploys — git push managed deploys, promotions to production, and rollbacks.
• Domains and TLS — domains added or removed, DNS changes, certificate events.
• Security — changes to WAF and rate-limiting policy, headers and allowlists, and password protection.
• Credentials — API keys created, revoked, or rotated; SSH access changes.
• Billing and plan — plan changes and payment-method updates.

Each entry records the actor (a member, or an API key acting on their behalf), the action, the target resource, a timestamp, and request context such as the originating IP and request_id. Read-only viewing isn’t logged — the log tracks changes, not glances.

API actions are attributed

When a service token or personal key performs an action, the entry names both the key and the human or service that owns it, so an automated deploy is just as traceable as a manual one.

Access and filter

Open Team → Audit log in the dashboard. The log is reverse-chronological and filterable by actor, action type, target site or project, and time range — so “show every deploy to the acme-corp project last week” or “every role change this member made” is a couple of clicks.

The Team → Audit log screen in the app.managed.dev dashboard, showing a filterable table of entries — each row with an actor avatar, action label, target site, and relative timestamp — plus filter chips for actor, action, and date range.

Using it for compliance and white-label

If you run sites for clients, the audit log is what turns “trust us” into evidence. Two common uses:

• Compliance. Demonstrate access control and change tracking for SOC 2-style reviews or client security questionnaires — every privileged action is attributable and timestamped.
• White-label accountability. When a client asks “who changed our site, and when?”, filter the log to their project and hand them a clean answer. Pair it with a scoped observer seat so they can self-serve.

Keep an external copy

For long-term retention or to pipe events into your own SIEM, the public API exposes audit entries for export and the webhook system emits events as actions happen. See account & teams in the API and webhook events.

Teams & rolesWho can do what — the actions the log records.

ProjectsFilter the log by project to isolate a client's activity.

Account & teams in the APIRead and export audit entries programmatically.