How to read the ImpulseCore audit log

Every state change across every Impulse module lands in one table. Filter by module, action, severity, or time — and drop to SQL when the admin UI isn't sharp enough.

Last updated 20 days ago

How to read the ImpulseCore audit log

The audit log is the single search surface across every Impulse module. Provisioning events, lifecycle transitions, customer self-service actions, cron failures, Security pipeline events, license verifications — everything that mutates customer-visible or operationally-significant state writes here.

The Audit tab

Open Addons → ImpulseCore → Audit. The default view shows the last 100 events across all modules, newest first. Four filters cover almost everything:

  • Module — narrow to one module by its slug (impulseminio, impulsedb-postgres, impulsecore itself).
  • Action — the dotted verb-object name like module.registered, server.provisioned, cron.task_failed, security_collect.run, patch.succeeded. The dropdown lists every action that's been emitted in the visible range.
  • Severity — info (default for normal events), warn, error. When triaging, filter to warn + error to see only what's misbehaving.
  • Time range — last 24h / 7d / 30d / 90d / custom.

There are also fields for Service ID, Admin ID, and Client ID — useful when you want one customer's full timeline, one admin's actions for the day, or every event scoped to a specific service.

The context column

Each row has a context column that's a JSON blob with structured details. The keys vary by action — for server.provisioned you'll see server_id and region; for cron.task_failed you'll see the exception class and message; for patch.succeeded you'll see the CVE id and snapshot id. Click a row to expand it inline; the JSON renders pretty-printed.

When you're investigating an issue, the context is usually where the actionable detail lives. The detail column is a one-line human-readable summary; context carries the structured facts you can grep or compare.

SQL fallback

When the admin UI filters aren't sharp enough — multi-condition queries, aggregations, joins — query the table directly:

SELECT * FROM mod_impulsecore_audit_log WHERE module_slug = ? AND created_at > ? ORDER BY created_at DESC;

Some queries the admin UI doesn't expose well:

-- Everything one customer triggered in the last 7 days SELECT created_at, module_slug, source, action, detail FROM mod_impulsecore_audit_log WHERE client_id = 1234 AND created_at > NOW() - INTERVAL 7 DAY ORDER BY created_at DESC; -- Top error sources from cron in the last 24h SELECT module_slug, action, COUNT(*) AS n, MAX(created_at) AS last_seen FROM mod_impulsecore_audit_log WHERE source = 'cron' AND severity = 'error' AND created_at > NOW() - INTERVAL 1 DAY GROUP BY module_slug, action ORDER BY n DESC;

What the source column tells you

Every row carries a source of admin, cron, customer, or system. Filtering by source is the fastest way to answer "who did this?" — for example source=admin AND admin_id=5 to see one admin's full day. The admin and customer sources populate ip_address; cron and system don't.

Retention

Default retention is 90 days, enforced by the audit_purge task daily. Change the cutoff under Settings → Audit → Retention (capped at 365 days in the UI; longer via mod_impulsecore_settings), or set it to 0 and pair with regular CSV exports.

Related