Workspace
Activity log
Use the DNS audit log to trace who changed a zone, connection, migration, member, or setting, with timestamps and details for operational review.
4 min read
On this page
The Activity page shows the workspace’s newest audited control-plane events: the stored action, target, a simplified actor label, and time. The key point is that the release UI labels only system rows as Worker; both user- and worker-originated rows appear as You, and teammate identities are not resolved.
Read the table#
Go to Activity. Every workspace role can view the page. It loads the newest 200 audit rows for the active workspace and displays four columns.
| Column | Meaning |
|---|---|
| Event | A friendly label for common connection, credential and migration actions; otherwise the stored action name |
| Target | The connection, migration, zone, email address or other object recorded by the service |
| By | Worker only when the stored actor is system; otherwise You. An available request IP appears beside it. |
| When | Relative time for the stored event timestamp |
Connection and credential rows use labels such as Connected a provider, Checked provider access, Removed a connection and Used stored credentials. Migration rows include Started a preview, Applied a migration, Verified a migration, Rolled back a migration and Deleted a migration. Actions without a label map appear in their dotted form, such as team.invite or zone.push.
Events recorded today#
The service writes audit entries around these web-reachable workflows:
| Area | Stored actions |
|---|---|
| Connections | connection.create, connection.verify, connection.remove, connection.purge |
| Credential use | credentials.decrypt, including a reason and provider in scrubbed metadata |
| Migrations | migration.create, migration.apply, migration.verify, migration.rollback, migration.remove, coupon.redeem |
| Managed zones | zone.create, zone.edit, zone.providers, zone.push, zone.restore, zone.remove |
| Cutover | cutover.start, cutover.revert |
| Team/workspaces | team.invite, team.revoke, team.join, team.role, team.remove, workspace.create |
| Notifications | notification.create, notification.remove |
| Billing | billing.checkout, billing.paid, billing.subscription |
| Bulk migration | bulk.start |
The audit event for automatic credential deletion is connection.purge. The Activity label map currently contains a label for credentials.purge instead, so a purge appears as the raw connection.purge action.
Not every database read or UI interaction creates an audit row. Opening pages, listing existing objects and printing a report are not audited. Notification tests and pause/resume changes are also not currently written to this log. The table should therefore be read as the set of explicit audited operations above, not a packet-level history of every request.
Credential-use entries#
When a user or worker loads an encrypted provider credential, the service writes credentials.decrypt after decryption. Its metadata includes the operation reason and provider ID. Reasons distinguish actions such as access verification, listing zones, source reads, provider writes, drift checks, backups and registrar cutover work.
The public Activity table does not display metadata, but the row target identifies the connection. The decrypt also moves that connection’s purge deadline forward. See Credential security for the encryption context and deletion lifecycle.
Provider access checks create two useful rows: credentials.decrypt for using the stored secret and connection.verify for the resulting status update. Creation writes connection.create after the initial check. Manual removal writes connection.remove; automatic expiration writes connection.purge.
Secret and metadata handling#
The audit helper filters top-level metadata property names that contain token, secret, password, key, credential or private, case-insensitively. This prevents normal callers from storing common secret fields in audit metadata. Provider credentials themselves are never intentionally written into an audit entry.
The Target column can contain operational identifiers and names. Request IP addresses appear only for actions whose service call passes the actor IP to the audit helper. Some background and older flows omit it.
Use Activity with migration evidence#
For an apply review, correlate:
Find the control action
In Activity, locate Applied a migration or the raw action you are investigating. Note its target and time.
Open the migration report
Use the migration’s Report page to inspect the saved preview plan counts, attention items, authoritative verification, and timeline. See Reports.
Check credential access
Look for nearby Used stored credentials and provider-access actions. A credentials row shown as You may have been written by the queued worker because the UI maps both user and worker actors to that label.
Retain external evidence where required
The Activity UI has no filter, search or export control. Capture the report and any provider-side audit record needed by your organization’s retention process.
Workspace isolation#
The service requires at least Member access and filters every Activity query by active workspace ID. Rows from another workspace are not returned merely because the same user belongs to both. Switch to the intended workspace before investigating an event.
The service-level audit list supports at most 500 rows per request, while the current page asks for 200. There is no pagination in the UI. For incidents involving older activity, combine migration timelines, provider-native logs and support assistance rather than assuming the web table contains the workspace’s full history.