Audit Log Entry Generator

The Audit Log Entry Generator produces batches of believable system audit-log records. It is built for engineers and compliance teams who need realistic event data to demo a SIEM, populate a security dashboard, or test audit-trail rendering and filtering without exposing any real activity.

How it works

The tool picks each field from curated banks — actors (including service accounts and a system principal), actions, resource paths, and outcomes weighted toward success with occasional failure and denied results. Each entry also gets a syntactically valid source IP and a realistic user-agent string.

Chronology is handled deliberately:

1. A timestamp is drawn for each entry within the last seven days.
2. All timestamps are sorted ascending before entries are assembled.
3. Each entry is emitted with an ISO 8601 timestamp, so the array reads as a genuine append-only trail.

Click Generate audit log to redraw, and Copy JSON to export the array.

Sample entry structure

Each generated record contains:

{
  "eventId": "evt_7f3a9c2d",
  "timestamp": "2024-11-14T09:47:32.000Z",
  "actor": "[email protected]",
  "action": "document.delete",
  "resource": "/api/v1/documents/contract-889",
  "outcome": "success",
  "sourceIp": "203.0.113.42",
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ..."
}

This structure mirrors what most cloud-provider audit logs (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) emit, and it maps directly to common SIEM schema formats. The domain.verb convention for action names (document.delete, permission.grant, auth.login) follows the pattern that OpenTelemetry and many security standards use.

Action categories

The generator spreads events across several action domains to produce a realistic mix:

• Authentication — auth.login, auth.logout, auth.mfa_verify, auth.password_change, auth.login_failed
• Record operations — record.create, record.read, record.update, record.delete, record.export
• Permission management — permission.grant, permission.revoke, role.assign, role.remove
• API access — api.key_create, api.key_revoke, api.rate_limit_exceeded
• Settings changes — settings.update, config.export, config.import

The mix is weighted: the majority of events are successful record reads and writes, with a smaller proportion of authentication events, and occasional failures and permission changes — which is how real production logs look.

Use cases

SIEM and security dashboards — populate a demo environment with enough event volume to show how the dashboards render timelines, actor frequency distributions, and failure-rate charts.

Compliance audit trail requirements — SOC 2, ISO 27001, GDPR, and HIPAA all require demonstrating that audit trails exist and are tamper-evident. Use generated entries to build test cases for your audit trail UI and export functionality.

Alert rule testing — test whether your monitoring rules fire correctly by generating a batch that includes a spike of auth.login_failed events from the same IP within a short time window, which should trigger a brute-force detection rule.

Log ingestion pipeline testing — verify that your ETL or log parsing pipeline handles all field types, timezone-normalized timestamps, and the full range of action strings without dropping or corrupting records.

Tips and notes

• The success-weighted outcome mix means you will usually see a handful of failure or denied events per batch — useful for testing alert rules and filters.
• Generate up to 200 entries at a time; rerun and concatenate for larger logs.
• Action names follow a domain.verb convention (for example permission.grant), which maps cleanly onto most audit schemas.
• All generation is local — no API key, no network call.