Streams deliver log files to your configured destination. Each log file contains log entries, formatted as JSON lines (JSONL). A log entry captures structured information about activity in your account for supported services, including what happened, who initiated the action, and when it occurred. The fields in each entry vary depending on the type of audit event.

Log files provide a detailed, event-level record of activity that helps you to reconstruct behavior, trace issues, and understand usage patterns. Logs help answer “who”, “what”, “when”, and "outcome" when investigating performance, reliability, or security concerns.

📘

Supported log types

Audit logs are currently in limited availability for select services. Support for additional log types and services is planned for future releases.

📘

Billing reconciliation

Audit logs may not reflect all billing-related events with complete accuracy. For consistent and reliable reconciliation, use the Billing API.

Audit logs

Audit logs are time-stamped records of Linode APIv4 operations and login events for supported services. Akamai collects and stores audit logs for 90 days, regardless of whether or not a stream is configured. Once a log entry is written, it can’t be altered, deleted, or overwritten.

Audit logs are delivered by the audit_logs stream type to your Object Storage bucket in batches. Each batch is stored as an object. Object naming follows the pattern defined in the stream configuration. If a path isn't specified, the default pattern is:

• Login audit logs: /audit_logs/com.akamai.audit/{account_id}/{Y}/{m}/{d}/akamai_log-{random_string}-{timestamp}-{random_string}-login.gz

  Example: /audit_logs/com.akamai.audit/3242234543/2025/08/27/akamai_log-000166-1756015362-319597-login.gz

• Configuration audit logs: /audit_logs/com.akamai.audit/{account_id}/{Y}/{m}/{d}/akamai_log-{random_string}-{timestamp}-{random_string}-config.gz

  Example: /audit_logs/com.akamai.audit/3242234543/2025/08/27/akamai_log-000166-1756015362-319597-config.gz

Within an object, you’ll find one or more log lines. The format of the log lines depends on the type of log.

Login audit logs

Login audit logs record successful logins to your account. They help you understand who accessed your account and from where. They provide important information like the timestamp, account, and user metadata. Login audit logs follow the CloudEvents v1.0.2 format and are delivered one event per line in JSONL format.

Example (formatted for clarity):

{  
  "specversion": "1.0",  
  "id": "99f77d13-b398-49f4-b747-24c457609c75",  
  "source": "/service/login",  
  "type": "com.akamai.audit.login",  
  "time": "2025-01-28T15:33:11.421Z",  
  "account": "33334444-2222-EEEE-0123456789ABCDEF",  
  "data": {  
    "username": "testuser",  
    "sourceip": "12.34.56.78",  
    "permissionlevel": "restricted",  
    "statuscode": "succeeded",  
    "statusmessage": "Successful login",  
    "type": "direct",  
    "email": "testuser@domain.com",  
    "useragent": "Mozilla/5.0 (..."  
  }  
}

Critical fields:

• id: A unique identifier for an event (log line). Useful for identifying duplicates. In rare cases, a single log entry is delivered multiple times.
• type: Always "com.akamai.audit.login" for login events.
• time: When the login occurred (UTC).
• account: The external UUID (euuid) of the account where the login occurred. If you have multiple accounts, you can find the euuid for each using the Linode API.
• data: Metadata about the login, including user details and client information.

Configuration audit logs

Configuration audit logs record changes made through the API or Cloud Manager. These logs help you to determine who made a change, what was changed, when, and whether it succeeded. It helps you trace operations like creating, modifying, or deleting entities. Logs contain details like the actor, the event code, the path, and so on.

Configuration audit logs also follow the CloudEvents v1.0.2 format in JSONL.

Example:

{
  "specversion": "1.0",
  "id": "1b9fd401-ad35-4dd8-88da-802e52d4503a",
  "source": "/service/linodes",
  "type": "com.akamai.audit.config",
  "time": "2025-01-28T15:33:11.123Z",
  "account": "33334444-2222-EEEE-0123456789ABCDEF",
  "data": {
    "actor": {
      "type": "user",
      "username": "testuser",
      "email": "testuser@domain.com",
      "sourceip": "12.34.56.78",
      "useragent": "Mozilla/5.0 (..."
    },
    "eventcode": "post-boot-linode-instance",
    "path": "api.linode.com/v4/linode/instances/123/boot",
    "request": {},
    "responsecode": 200,
    "response": {},
    "requestid": "9097a7cd-86ed-4b7e-a607-613cb6693c41"
  }
}

Critical fields:

• id: Unique identifier for the log entry (log line). Useful for identifying duplicates. In rare cases, a single log entry is delivered multiple times.
• type: Always "com.akamai.audit.config" for configuration events.
• time: When the configuration change occurred (UTC).
• account: The external UUID (euuid) of the account where the event occurred. If you have multiple accounts, you can find the euuid for each using the Linode API.

Key data fields:

• data: Information about the caller, what they attempted to change, and the result.
• data.actor: The identity of the user or system that initiated the change.
• data.eventcode: Identifies the API event type (operation). You can append the event code to the URL for the Linode API reference documentation to learn more about the operation, for example, https://techdocs.akamai.com/linode-api/reference/post-boot-linode-instance.
• data.path: The resource path affected.
• data.request: The user-submitted request parameters (with sensitive data redacted).
• data.responsecode: The status code indicating success or failure.
• data.response: The API response body with sensitive data redacted. This is only returned for successful requests.
• data.errors: Errors returned during the request. This is only returned for unsuccessful requests.
• data.requestid: A unique identifier for the request that initiated a configuration change. If there are multiple logs for a single request, you can use this identifier to correlate with other requests sharing the same request id.

Log redaction

Audit logs intentionally capture the details needed to reconstruct the changes that users made. As part of this, properties specified in an API request and response bodies are logged. To ensure sensitive information is not recorded, audit logs only include valid, non-sensitive, request and response fields.

Sensitive data includes:

• Passwords
• Tokens
• Keys
• Personally identifiable information (PII)
• Freeform string data

Sensitive data is replaced with [REDACTED].

Resource labels, tags, usernames, and email addresses are not redacted because they're essential for constructing an audit trail, so it's best to avoid including sensitive information in these. Additionally, it's a good idea to limit audit log visibility to only those users who are authorized to see them.

Invalid or malformed request bodies and invalid properties are omitted. Invalid properties include malformed JSON, incorrect types (for example, a string where an integer is expected), and fields that aren’t part of an API’s valid input.

Log truncation

Individual log entries may be truncated if they exceed the 64KB maximum size. Truncation is applied carefully so that entries remain valid JSON and retain as much detail as possible.

Three truncations may occur:

• Long strings are shortened with ". . ." appended.
• Response content may be elided to prioritize request properties. If so, the log entry will include "responselided": true and the response field becomes null.
• Very long arrays may be truncated, keeping only a subset of the array items. A <arrayname>__tl field appears indicating the original array length. For example, items__tl: 30 indicates that the items array was truncated and its original length was 30.

These rules help ensure logs remain usable while respecting size limits.