Audit logs

Dew’s audit log records who did what, to what, from where, and whether it worked: sign-ins, shared links and downloads, user and admin changes, settings changes, and server starts and stops. Admins read it in Dew, and security teams can send it to a SIEM such as Splunk, Elastic, Microsoft Sentinel or QRadar. Audit logs are part of the Enterprise plan.

What each event tells you

Every event names a person or system and the thing they acted on in readable form, so you can read it without looking up IDs.

Who: a signed-in user, a service account (through its API token), an SSO connection (for SCIM provisioning, and for accounts created or updated when someone signs in with SSO), someone outside the app (a link recipient or an uploader), or the system itself (a scheduled cleanup, for example).
What: the event, for example File downloaded or Sign-in failed, and whether it succeeded. A refused attempt is the same event marked as failed, with a reason such as wrong_password or expired.
To what: the file, user, setting or connection. Its name is kept even after it is deleted.
Where from: the visitor’s IP address and browser or app. Behind a reverse proxy, this needs the proxy listed as trusted.
What changed: for edits, the old and new value of each field. Passwords and other secrets show only that they changed.

The event reference lists every event and its details.

Read the audit log in Dew

Open Activity → Audit logs to search and filter events. Click Export to download every event matching your filters as a file with one JSON record per line. Exports are recorded in the audit log too.

Send events to your SIEM

Dew offers two ways to get events into a SIEM: a feed your SIEM polls over HTTPS, and a log file a collector reads from the server. Both deliver the same records. See Send audit logs to a SIEM.

How long events are kept

Dew keeps audit events for 90 days by default. Change it in Settings → General settings: choose Global Defaults in the scope menu at the top, then set Users & Access → Audit log retention to a value between 30 days and 10 years (3650 days). Older events are deleted every hour.

Changing the setting is recorded with the old and new value.
Lowering it sends every admin a notification and an email.
Each cleanup is recorded as Expired audit events deleted.

To keep events longer than Dew does, send them to your SIEM or to write-once storage.

What you can rely on

No event is lost once its action is saved. If Dew’s database is unavailable, the event is saved on the server’s disk and added in order once the database is back, also after a restart.
Nobody can edit or delete an event in Dew. Only the retention setting removes events, and every removal is recorded.
The most recent 30 days are always kept, because retention can’t go lower.
Unexpected shutdowns show up. Every server start and clean stop is recorded. A Server started event with no Server stopped before it means the server stopped without shutting down: a crash, a killed process or a power loss. Set an alert on it in your SIEM.
Failed attempts are recorded, such as a wrong password, a wrong code or a revoked token. Refused attempts to open a link or use a token are recorded up to 10 times per IP address and link or token every 10 minutes. When a signed-in user or an API token is refused access to a page or action, up to 10 refusals per user or token and reason are recorded every 10 minutes. Requests Dew turned away for sending too many attempts (rate limited) are on the Access logs tab of System → System instead.

Some limits to know:

An action is saved first, then its event. If the server crashes between the two, the action has no event.
People with direct access to the server’s database or log files are outside what Dew can protect. For a record nobody on the server can change, send events to your SIEM or to write-once storage.
Audit events include link IDs, and anyone with a link ID can open that link. Protect your SIEM index and exports as you would the links themselves.