Audit trail

Audit trail lets you monitor all the actions performed in your account, whether through the Customer Portal, the Public API, or by the system.

An event is a record of an action taken by a user or by the system — for example, a sign-in attempt, ordering or canceling a server, or changing a permission. Audit trail collects these events into a chronological list.

Event collection is active by default. There's nothing to configure.

Use cases

Reviewing account activity

Use the Audit trail to see who did what and when — for example, to confirm who ordered or canceled a server, or who changed a permission policy.

Investigating sign-in activity

If you need to review who accessed your account and when, check the sign-in events in the Audit trail. Account members who have granted PII consent will also show IP address, location, and device/browser details for their sign-ins, which is useful when investigating a suspicious sign-in.

Building your own monitoring

You can pull events from our Public API into your Grafana instance or SIEM solution to build custom dashboards, reports, and alerts.

Sign-in logging and PII consent

Every time a known account member signs in, Audit trail logs a sign-in event for each account they access during that session. The event shows whether the sign-in succeeded, plus the member's identity and membership details. Sign-in attempts with credentials that don't match any account member aren't logged.

By default, a sign-in event shows only non-personal details. A member can choose to share more: IP address, location, and device/browser details. To do this, they grant consent from their Customer Portal user profile. This information is visible to everyone who has access to the Audit trail.

• Consent applies to one account membership at a time. A member who belongs to several accounts must log in to each one and grant or revoke consent separately there.
• A member can grant or revoke consent at any time. The change takes effect right away.
• Revoking consent stops new personal details from being logged. Details already logged stay in the history.
• Granting or revoking consent is itself logged as an event.

To grant or revoke consent:

1. Go to your Customer Portal user profile.
2. In the Account membership section, click Audit log consent.
3. Click Grant (or Revoke to revoke consent).

Repeat this for each account you belong to.

Audit trail access permissions

You can restrict access to the Audit trail, since not every account member should be able to see event history.

Access is controlled by a dedicated permission. It's enabled by default in the Default administrative policy. For any other administrative policy, turn it on yourself.

Without it, members can't see the Audit trail tab or open the Event details page, even via a direct link.

To turn on this permission:

1. Go to Permission policies tab.
2. Open the policy you want to edit, or create a new one (see Identity and Access Management).
3. Set Permission scope to Administrative permissions, if it isn't already.
4. In Permission settings, open Audit Trail and check Read.
5. Click Save.

Limitations

• Guaranteed retention is 90 days. The Customer Portal may show older events, but we only guarantee 90 days of availability.

• Unmatched sign-in attempts aren't logged. A sign-in attempt with credentials that don't match any known account member doesn't produce a sign-in event.

Billing

Audit trail is included with your account at no extra cost. Event collection is active by default and requires no setup.

Getting started

1. Log in to the Customer Portal and navigate to Monitoring → Audit trail. You'll see a list of events for your account.
2. Use the filters to narrow the event list by user, resource type, event, resource, or date.
3. Click an event's title to open the Event details page. It shows a card with the event's key facts plus a full event payload as JSON, which you can copy to the clipboard.

How events are displayed

• If a resource has been deleted, its events remain visible in the event list, but the Resource field shows its name prefixed with [deleted] — for example, [deleted] cloud_instance. The resource's name is also available in the payload on the Event details page.
• If the system triggered the action rather than an account member, the User field is left empty.