Time when the audit log was recorded, in UNIX timestamp milliseconds (in UTC).

Indicates the application within the platform. Possible values include api, alert, search, ts_user_action, and identity_sync.

See Audit Logs for Security Analytics for more information on events that are audited within these applications.

api

Captures information about API calls that a user makes, including but not limited to:

• user that made the API call

• HTTP method (GET, POST, and so on)

• URI of the request

• Search Job ID of the search, and more.

Audit your API call

Here's a typical search query to audit your API calls:

audit | where app = "api"

How do I check if my API call failed?

The following query should help you check what about your API call failed:

audit | where app = "api" and status_code = 400

This query helps you check which API calls failed and returned the 400 status code. For example,you can use the request_uri, search_query, and response_digest fields to analyze the error.

{"message": "line 1:26 missing ')' at '<EOF>'"}

In the example response_digest JSON object above, the search query is wrong since it is missing a ')'.

alert

Captures all the details about alerts, including the alert status, any events that were throttled, and the response after the alert is triggered.

How do I check if a scheduled alert failed?

Since alerts send JSON response payloads, use the json_extract function in the calc operator to filter the results as per the alert status, as follows:

Step 1: Audit alerts using the following query:

audit | where app = "alert"

Step 2: Filter the results based on the status of these alert results from Step 1.

audit | where app = "alert" | calc status = json_extract(response_digest, "status") | where status = 'FAILED'

This query will return all the failed alerts, including the response_digest and request_payload that specifically point out what went wrong in the alert.

Step 3: Check the alert request payload. For example, this is a cron-based alert:

{"alert_id": 2517, "schedule": "* * * * *", "alert_name": "maj test alert", "event_count": "3"}

Step 4: Check the response digest. It indicates the provided request URI was invalid (400 Bad Request):

{
"status": "FAILED", 
"message": "400 Client Error: 
  Bad Request for url: https://hooks.slack.com/services/T1PC73GUX/B01ZE0/Zzpy96"
}

How do I check which are the common types of alert failure?

The following query counts the frequency of all the types of alert failures:

audit 
| where app = "alert" 
| calc status = json_extract(response_digest, "status") 
| where status = 'FAILED'
| calc error_message = json_extract(response_digest, "message") 
| aggr count as total_counts by error_message 
| sort total_counts desc

search

Captures details about various searches, including:

• search query

• search job ID

• total number of results returned and records scanned

• Anomali Virtual Compute (AVC) units consumed by the search

• total runtime (the amount of time elapsed before getting results)

• whether a search was a saved search

ts_user_action

Captures ThreatStream user actions. See Audit Lookup Table (ThreatStream) for the list of available ThreatStream user actions.

identity_sync

Captures identity provider synchronization events, such as user and group provisioning updates between the platform and an external identity provider.

The category of user action that was logged, including api and ui.

The platform user who initiated the action. This value is the email address of the user.

Type of the activity recorded, including create, update, delete, submit_job, and so on. Combine this field with the category field to identify what the action was performed on. See Audit Logs for Security Analytics for more information on the different types of auditable actions.

IP address of the client that initiates the activity.

The date and time (local time) the activity was recorded. For example, Mar 13, 2025 17:50:15.000 -07 denotes a search was launched on March 13th at 5:50 PM (UTC-7).

Total time taken (in milliseconds) to execute the search or API request.

The user agent of the client that performed the request.

The method used in an HTTP request, such as GET, POST, and so on.

The HTTP status code returned in response to the request.

The query submitted by the user. For example:

 'eventlog | where sourcetype = "ts_onprem" and match(subject,"(ts-[a-z]+|postgresql): FAIL") | fields subject, host'

The name of the saved search. This lets you determine which searches are run through search queries in the AQL Search Box and searches that arise from saved searches.

Start of the event_time time range for the search event, in UNIX timestamp milliseconds (UTC).

End of the event_time time range for the search event, in UNIX timestamp milliseconds (UTC).

The unique ID of a submitted Search job. This is typically a 32-character alphanumeric ID.

URI of the requested HTTP resource.

The HTTP request body, in JSON format. You can use it to obtain information about your search. For example, in the following payload:

{"origin": "event_search", "total_avc": 0.16}

the 'origin' key tells you that the search originated from a event search. Other possible sources of origins are from a dashboard or an alert.

See the AQL calc operator to understand how you can use json_extract to filter your audit results based on the fields in the request body.

The summary of the response content, typically in JSON format. See the AQL calc operator to understand how you can use the json_extract function to filter your audit results. For example, you can filter down a failed alert using the json_extract function based on the fields in the response, as follows:

audit | where app = "alert" | calc status = json_extract(response_digest, "status") | where status = 'FAILED'

This query returns all the failed alerts, an error message that indicates the error in the alert, the total number of events and throttled events.

The total size of the request body and headers (in bytes).

The total size of the request body and headers (in bytes).

User submitted a job for the feature specified in the category field, for example, search.

User created the object specified in the category field.

User updated the object specified in the category field.

User appended data to the lookup specified in the category field.

A scheduled alert ran for the item specified in the category field.

User set a status or disposition on the alert specified in the category field.

An alert email notification was sent for the alert specified in the category field.

A job ran for the feature specified in the category field, for example, search.

User created the lookup specified in the category field.

User appended data to the lookup specified in the category field.

added-permission

The user granted a user permission on the ThreatStream Settings > User Admin page.

created

logout

removed-permission

signed-in

The user signed in by specifying their user name and password.

updated

An identity was created or discovered during an identity sync. The request_payload field lists the identities (for example, user email addresses or account names) found by the connector specified in the category field.

An identity connector (for example, a GCP IAM connector) completed a sync for the connector specified in the category field. The response_digest field reports the sync outcome (success or failed), the connector type, the number of records processed and failed, and the sync duration.