# How to Use Event Logs in Retool

- Tool: Retool
- Difficulty: Beginner
- Time required: 15-20 min
- Compatibility: Retool Cloud (Business and Enterprise)
- Last updated: March 2026

## TL;DR

Retool's audit log is at Settings → Audit Log (Business+ plans). Each entry has actor (who), action (what), resource (which app/query), and timestamp. Filter by user, action type, date range, or app. Download as CSV for compliance. UI shows 3 months of history; downloaded exports include up to 1 year. The audit log is read-only — you cannot modify or delete entries.

## What the Retool Audit Log Records and How to Read It

Retool's audit log is the compliance and security record of all significant actions taken in your Retool organization. Every user login, app view, query execution, permission change, and configuration modification generates an audit log entry.

The audit log is essential for: security investigations (who accessed what, when), compliance reporting (SOC 2 evidence, GDPR data access records), troubleshooting unexpected changes (who modified an app or query), and access control audits (which users have which permissions).

This tutorial covers navigating the audit log UI, understanding the log fields, filtering for specific events, and exporting logs for external use.

## Before you start

- Admin access to your Retool organization
- Retool Business or Enterprise plan (audit log requires Business+)
- A specific event or time range you want to investigate

## Step-by-step guide

### 1. Navigate to the Retool audit log

Log in to Retool as an admin. Navigate to Settings (gear icon, bottom-left) → Audit Log. The audit log page shows a chronological list of events in your organization with the most recent events at the top. If you see a 'Feature not available on your plan' message, your organization is on the Free or Pro plan. The Retool Cloud URL for audit logs is typically: https://[your-org].retool.com/settings/audit.

**Expected result:** Audit log page loads showing recent events with actor, action, timestamp, and resource columns.

### 2. Understand the audit log entry fields

Each audit log entry contains four key fields: (1) Actor — the user who performed the action (email address). 'System' indicates an automated Retool action. (2) Action — what happened (e.g., 'app_view', 'query_execution', 'permission_granted', 'login_success', 'login_failure', 'resource_created'). (3) Resource — the app, query, resource, or user affected. (4) Timestamp — when the event occurred (UTC). Some entries have additional metadata in a Details column showing parameters or context.

**Expected result:** You can read and interpret individual audit log entries.

### 3. Filter audit log entries by user

Use the Filters panel on the left (or the filter bar at the top) to narrow down events. To find all actions by a specific user, enter their email in the 'Actor' filter. This is useful for: investigating suspicious activity by a specific user, reviewing what a departing employee accessed before offboarding, or confirming a user completed a required training task (if tracked via app views).

**Expected result:** Audit log filtered to show only events for the specified user.

### 4. Filter by action type to investigate specific events

Filter by the 'Action' field to find specific event types. Common action types to filter for: 'login_failure' (failed login attempts — investigate spikes), 'permission_granted' (who got new permissions), 'resource_created' or 'resource_deleted' (database resource changes), 'app_shared' (app sharing events), 'user_invited' or 'user_removed' (team membership changes). Combine multiple action type filters to narrow down investigation.

```
// Common action types in Retool audit log:
// Authentication: login_success, login_failure, logout, sso_login
// Apps: app_view, app_created, app_deleted, app_edited, app_shared
// Queries: query_execution, query_created, query_deleted
// Resources: resource_created, resource_updated, resource_deleted
// Permissions: permission_granted, permission_revoked, group_created
// Users: user_invited, user_activated, user_deactivated, user_removed
// Settings: config_changed, api_key_created, api_key_revoked
```

**Expected result:** Filtered view showing only the specific action types relevant to the investigation.

### 5. Set a date range for the investigation

Use the date range picker at the top of the audit log to set a specific time window. For incident investigations, set the range to the suspected incident timeframe (e.g., the 24 hours before a data issue was discovered). For compliance reports, set a monthly or quarterly range. The UI shows up to 3 months of data. For events older than 3 months, use the CSV export which includes up to 1 year of history.

**Expected result:** Audit log filtered to the specified date range showing only events within that window.

### 6. Export audit logs for compliance and external analysis

Click the 'Export' or 'Download CSV' button to download audit log data as a CSV file. The export includes all visible events after your current filters are applied, or the full date range if no filters are active. The CSV contains all log fields: timestamp, actor, action, resource_type, resource_name, ip_address, and details. For SOC 2 Type II compliance, export quarterly and store in your compliance evidence repository.

**Expected result:** CSV file downloaded containing audit log entries for the selected date range and filters.

## Complete code example

File: `SQL Query: analyzeExportedAuditLogs`

```sql
-- This SQL is for analyzing exported audit log CSV data
-- after importing it into your own database or data warehouse
-- (e.g., BigQuery, Redshift, PostgreSQL)

-- Most active users in the last 30 days
SELECT
  actor_email,
  COUNT(*) AS total_events,
  COUNT(DISTINCT DATE(timestamp)) AS active_days,
  COUNT(CASE WHEN action = 'query_execution' THEN 1 END) AS query_executions,
  COUNT(CASE WHEN action = 'login_failure' THEN 1 END) AS failed_logins
FROM retool_audit_log
WHERE timestamp >= NOW() - INTERVAL '30 days'
GROUP BY actor_email
ORDER BY total_events DESC
LIMIT 20;

-- Failed login attempts (potential brute force)
SELECT
  actor_email,
  COUNT(*) AS failed_attempts,
  MIN(timestamp) AS first_attempt,
  MAX(timestamp) AS last_attempt
FROM retool_audit_log
WHERE action = 'login_failure'
  AND timestamp >= NOW() - INTERVAL '24 hours'
GROUP BY actor_email
HAVING COUNT(*) >= 5
ORDER BY failed_attempts DESC;
```

## Common mistakes

- **Looking for query-level data (what records were read) in the audit log and finding only metadata** — undefined Fix: Retool's audit log records query execution events (who ran which query, when) but not the data returned. For data-level audit trails, implement application-level logging in your own database using INSERT into an audit_trail table on every sensitive query.
- **Expecting audit log data older than 3 months to appear in the UI** — undefined Fix: The Retool audit log UI shows only the last 3 months. For historical data, export to CSV (up to 1 year) or configure Enterprise audit log streaming to an external service for unlimited retention.
- **Not filtering by date range and getting overwhelmed by thousands of log entries** — undefined Fix: Always start with a date range filter before applying other filters. Narrow to the smallest timeframe that contains the events you're investigating.

## Best practices

- Review failed login spikes weekly — multiple login_failure events for one user in a short window may indicate a compromised account
- Audit permission_granted events monthly to ensure principle of least privilege is maintained
- Export and archive audit logs quarterly for compliance — don't rely solely on the 3-month UI retention
- For Enterprise plans, configure audit log streaming to your SIEM (Datadog, Splunk) for automated alerting on suspicious patterns
- When investigating a security incident, start with login events for the suspected timeframe, then trace the actor's subsequent actions

## Frequently asked questions

### Can I set up automated alerts based on audit log events in Retool?

The Retool audit log UI does not have built-in alerting. For automated alerts (e.g., email on login_failure spikes), use Enterprise audit log streaming to Datadog or Splunk and configure alerts in those platforms. Alternatively, build a Retool Workflow that queries your audit log data on a schedule and sends notifications via email or Slack.

### What is the difference between Retool audit logs and application-level logging?

Retool audit logs record Retool platform events: who logged in, which apps were viewed, which queries were run. Application-level logging records what your app's queries did to your data: which records were read, inserted, or updated. For a complete picture, you need both: Retool audit logs for the 'who accessed Retool' and application-level logging for 'what data was accessed or changed.'

### Can non-admin users access the Retool audit log?

No — the audit log is accessible only to Retool organization admins. Individual users can see their own activity in the Retool account settings page, but org-wide audit logs are admin-only. If you need to share audit data with security or compliance teams, export to CSV and share the file.

---

Source: https://www.rapidevelopers.com/retool-tutorial/how-to-use-event-logs-in-retool
© RapidDev — https://www.rapidevelopers.com/retool-tutorial/how-to-use-event-logs-in-retool