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,impulsecoreitself). - 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 towarn+errorto 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
Was this helpful?
More in ImpulseCore
Blank page after activating ImpulseCoreFix: "Class not found: ImpulseCore" when activating a moduleCron Health panel shows every task redCron Health shows one task failing while others are greenStill need help? Ask the team