Skip to main content
ImpulseCore

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 6 months 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