> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataraven.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Audit Logs
> Track every action across your team with a complete, tamper-proof event trail.
DataRaven records every meaningful action that happens within your team — whether triggered by a user, an API key, or the system itself. The audit log gives you full visibility into who did what, when, and from where.
Every create, update, and delete performed through the dashboard or API.
Scheduled task executions, transfer completions, and failures — logged automatically.
IP address, user agent, and request ID captured with every user-initiated event.
## Viewing the Audit Log
The audit log is accessible in two places within the dashboard:
* **Activity Feed** — The dashboard homepage shows the 10 most recent events at a glance, so you can quickly see what's been happening.
* **Event Log** — A dedicated page at **Event Log** in the sidebar provides the full audit trail with filtering, pagination, and CSV export.
Any team member with **Viewer** role or higher can access the audit log.
## Filtering & Export
The Event Log page supports filtering by:
| Filter | Description |
| ----------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Resource type** | Narrow to a specific resource — tasks, executions, secrets, locations, members, notifications, or vault connections. |
| **Actor type** | Show only events from users, the system, or API keys. |
| **Date range** | Filter events to a specific time window. |
You can **export the current view to CSV** for compliance reporting, incident investigation, or offline analysis. The export includes all fields: timestamp, event type, resource, actor, summary, IP address, user agent, and request ID.
## What Gets Recorded
Every audit log entry captures a core set of fields, plus optional context depending on who triggered the action.
### Common Fields
Every event includes:
| Field | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------------- |
| **Event type** | What happened (e.g., `task_created`, `execution_completed`). |
| **Resource type** | What was affected — `task`, `execution`, `secret`, `location`, `member`, `notification`, or `vault_connection`. |
| **Resource ID** | The unique identifier of the affected resource. |
| **Resource name** | A human-readable name for the resource (where applicable). |
| **Actor type** | Who did it — `user`, `system`, or `api_key`. |
| **Actor name** | The name or email of the person or system that triggered the event. |
| **Summary** | A plain-English description of what happened. |
| **Metadata** | Structured key-value data specific to the event (see tables below). |
| **Timestamp** | When the event occurred (UTC). |
### Request Context (User Actions Only)
When an event is triggered by a user or API key through the dashboard or API, additional request context is captured:
| Field | Description |
| -------------- | -------------------------------------------------------------------------------------- |
| **IP address** | The originating IP, resolved via `cf-connecting-ip` (Cloudflare) or `x-forwarded-for`. |
| **User agent** | The browser or HTTP client used. |
| **Request ID** | A unique correlation ID for the HTTP request, useful for debugging. |
System events (scheduled executions, background workers) do not have request context since they originate from internal processes, not HTTP requests.
## Event Reference
Below is a complete reference of every event type recorded by the audit log, organized by resource.
### Task Events
Recorded when transfer tasks are created, modified, or removed.
| Event Type | Trigger | Summary Example | Metadata |
| --------------- | ------- | ------------------------------- | ----------------------------------------- |
| `task_created` | User | Created task "Daily S3 Backup" | `task_type` (copy, sync) |
| `task_updated` | User | Updated task "Daily S3 Backup" | `updated_fields` — list of changed fields |
| `task_enabled` | User | Enabled task "Daily S3 Backup" | `status: enabled` |
| `task_disabled` | User | Disabled task "Daily S3 Backup" | `status: disabled` |
| `task_archived` | User | Archived task "Daily S3 Backup" | `status: archived` |
| `task_deleted` | User | Deleted task "Daily S3 Backup" | — |
### Execution Events
Recorded across the full lifecycle of a transfer execution — from submission through completion or failure. Execution events come from both user actions and the system.
These events are initiated by a user through the dashboard or API and include full request context (IP, user agent, request ID).
| Event Type | Summary Example | Metadata |
| --------------------- | ---------------------------------------------- | ------------------------------------- |
| `execution_submitted` | Submitted execution for task "Daily S3 Backup" | `trigger` (manual, api), `is_dry_run` |
| `execution_cancelled` | Cancelled execution for task "Daily S3 Backup" | — |
These events are generated by background workers and scheduled jobs. They do **not** include request context.
| Event Type | Summary Example | Metadata |
| ----------------------------- | ---------------------------------------------- | ----------------------------------------- |
| `execution_submitted` | Submitted execution for task "Daily S3 Backup" | `trigger: scheduled`, `is_dry_run: false` |
| `execution_started` | Started execution for task "Daily S3 Backup" | — |
| `execution_completed` | Completed execution for task "Daily S3 Backup" | `stats` (transfer statistics), `error` |
| `execution_failed` | Failed execution for task "Daily S3 Backup" | `stats`, `error` (error message) |
| `execution_pending` | Pending execution for task "Daily S3 Backup" | `stats`, `error` |
| `execution_running` | Running execution for task "Daily S3 Backup" | `stats`, `error` |
| `execution_dry_run_completed` | Dry run completed for task "Daily S3 Backup" | `stats`, `error` |
Scheduled task executions are logged with `trigger: scheduled` and actor name **"Scheduled"**, making it easy to distinguish automated runs from manual ones.
### Secret Events
Recorded when cloud provider credentials are created, modified, or removed.
| Event Type | Trigger | Summary Example | Metadata |
| ---------------- | ------- | ------------------------------- | ---------------------------------------------------------------- |
| `secret_created` | User | Created secret "Production AWS" | `secret_type` (e.g., aws\_s3, azure\_blob) |
| `secret_updated` | User | Updated secret "Production AWS" | `updated_fields` — list of changed fields (credentials excluded) |
| `secret_deleted` | User | Deleted secret "Production AWS" | — |
For security, the `updated_fields` metadata for secret updates intentionally **excludes** the `credentials` field — you'll see which fields changed, but credential values are never logged.
### Location Events
Recorded when storage locations are created, verified, modified, or removed.
| Event Type | Trigger | Summary Example | Metadata |
| ------------------- | ------- | ---------------------------------- | -------------------------------------------- |
| `location_created` | User | Created location "s3-prod-bucket" | `location_type` (e.g., aws\_s3, gcs) |
| `location_updated` | User | Updated location "s3-prod-bucket" | — |
| `location_verified` | User | Verified location "s3-prod-bucket" | `verified` (true/false), `error` (if failed) |
| `location_deleted` | User | Deleted location "s3-prod-bucket" | — |
### Vault Connection Events
Recorded when external vault integrations (1Password, Doppler, Infisical) are managed.
| Event Type | Trigger | Summary Example | Metadata |
| -------------------------------- | ------- | --------------------------------------------------- | -------------------------------------------------- |
| `vault_connection_created` | User | Created vault connection "1Password Prod" | — |
| `vault_connection_tested` | User | Tested vault connection "1Password Prod" | `success`, `message`, plus provider-specific stats |
| `vault_connection_updated` | User | Updated vault connection "1Password Prod" | `updated_fields` — list of changed fields |
| `vault_connection_token_rotated` | User | Rotated token for vault connection "1Password Prod" | — |
| `vault_connection_deleted` | User | Deleted vault connection "1Password Prod" | — |
### Notification Events
Recorded when webhook or notification configurations are managed.
| Event Type | Trigger | Summary Example | Metadata |
| ---------------------- | ------- | ----------------------------------- | --------------------------------------------------------------- |
| `notification_created` | User | Created notification "Slack Alerts" | `event_type` — the execution event this notification listens to |
| `notification_updated` | User | Updated notification "Slack Alerts" | — |
| `notification_deleted` | User | Deleted notification "Slack Alerts" | — |
### Member Events
Recorded when team membership changes — invitations, joins, role changes, and removals.
| Event Type | Trigger | Summary Example | Metadata |
| --------------------- | ------- | --------------------------------------------------------------------- | -------------------------------- |
| `member_invited` | User | Invited member "[jane@example.com](mailto:jane@example.com)" | `role` (viewer, operator, admin) |
| `member_joined` | User | Member joined the team | `role` |
| `member_role_changed` | User | Changed role for member "[jane@example.com](mailto:jane@example.com)" | `new_role` |
| `member_removed` | User | Removed member "[jane@example.com](mailto:jane@example.com)" | — |
## Actor Types
Every event is attributed to an actor. DataRaven distinguishes three types:
| Actor Type | Description | Request Context |
| ----------- | -------------------------------------------------------------------------------- | ---------------------------------- |
| **User** | A team member acting through the dashboard or API. Identified by name and email. | IP address, user agent, request ID |
| **System** | An internal process such as the task scheduler or execution worker. | None — internal origin |
| **API Key** | An external integration authenticating via API key. | IP address, user agent, request ID |
## Scheduled Execution Tracking
When a task has a cron schedule configured, DataRaven's scheduler automatically submits executions at the defined intervals. These scheduled runs are fully tracked in the audit log:
* **`execution_submitted`** is logged with `trigger: scheduled` and actor name **"Scheduled"**
* **`execution_started`**, **`execution_completed`**, and **`execution_failed`** are logged as the execution progresses through its lifecycle
* Transfer statistics (files transferred, bytes moved, errors) are captured in the `stats` metadata field on completion
This means you can audit the complete history of your automated transfers — when they ran, whether they succeeded, and how much data was moved — without any manual intervention.
## Data Retention
Audit logs are retained for the lifetime of the team. When a team is deleted, all associated audit log entries are permanently removed.
## API Access
Audit logs are available via the REST API at:
```
GET /teams/{team_id}/audit-logs
```
**Query parameters:**
| Parameter | Type | Description |
| --------------- | -------- | -------------------------------------- |
| `resource_type` | string | Filter by resource type |
| `event_type` | string | Filter by event type |
| `actor_type` | string | Filter by actor type |
| `start_date` | ISO 8601 | Filter events from this date |
| `end_date` | ISO 8601 | Filter events until this date |
| `page` | integer | Page number (default: 1) |
| `limit` | integer | Items per page (default: 25, max: 250) |
Requires **Viewer** role or higher on the team.