Skip to content
Mumara

Account control · audit trail

Every action. Every actor. Every timestamp. Indexed.

When a campaign goes out wrong, when a contact disappears, when a sending limit gets bumped — the question is always the same: who, what, when. Activity Logs is the answer. Every admin and user action across the platform, recorded with the actor, the target, the IP, the timestamp. Searchable. Exportable. Retention-configurable.

Get started Authentication Logs →
  • Every action — create, edit, delete, schedule, send, suppress, configure
  • Every actor — admin, user, API token
  • Filter — by actor, action, target type, time window
  • Export — CSV out for SIEM ingestion or audit

Activity Logs

Today · 7 entries · all actors

Filtering by today
  • CREATE

    Broadcast: May Newsletter #38

    Aisha Karim

    14:22
  • EDIT

    Segment: Highly Engaged

    Marcus Wei

    13:55
  • SCHEDULE

    Drip: Welcome series → Newsletter list

    Aisha Karim

    11:08
  • DELETE

    Contact: 19 imported rows (bulk)

    Devi Patel

    10:40
  • SUPPRESS

    Domain: yahoo.com (CIDR import)

    Jonas Riedel

    09:12
  • UPDATE

    Sending node: Amazon SES — hourly limit 30k → 50k

    Marcus Wei

    08:47
  • CREATE

    API role: Read-only auditor

    Aisha Karim

    08:31
Showing 1 – 7 of 247 today Export CSV

Captured by default

No instrumentation. No agent. Just on.

Activity Logs runs by default on every Mumara Campaigns installation. You don't configure what's tracked — the platform records every action that mutates state, automatically.

mutation is recorded
Every
mutation is recorded
Create, edit, delete, schedule, send, suppress, configure — across every resource on the platform.
filtering
Multi-axis
filtering
Actor, action type, target type, time window — combine freely for incident investigation.
export for SIEM
CSV
export for SIEM
Pipe activity into Splunk, Datadog, Elastic, or a flat-file archive. Native CSV download from the UI.
retention window
Configurable
retention window
Auto-delete after X days (your choice) to match your data-retention policy and storage budget.

Filter, find, export

Multi-axis filtering, then download what you need.

The Activity Logs UI is built around the question 'who did this'. Filter by actor, action type, target type, and date range — combine the axes freely until the result set is small enough to read. Click any entry for the full per-event detail (payload diff included where relevant). Export the filtered set as CSV to attach to a ticket, feed your SIEM, or archive separately.

  • Multi-axis filters combine freely

    Pick an actor (specific admin, user, or API token), an action verb (delete, edit, schedule), a target type (Broadcasts, Contacts, Sending Nodes), a date window. The result set narrows live; the count updates per filter.

  • Clear filters in one click

    Hit Clear filters to wipe every axis at once. Useful when bouncing between investigations on the same page.

  • Per-entry detail on click

    Click any log row to see the full event — actor, IP, target identifier, timestamp, and (where applicable) a field-level diff of what changed. The depth most audit surfaces hide.

  • CSV export for offline analysis

    The Export CSV button respects the active filter. Attach to compliance tickets, pipe into your SIEM, or archive for long-term retention.

Mumara Activity Logs filter UI — four filter pills (actor, action, target, date) with active selections, three filtered DELETE results, Export CSV button

Three log surfaces

Activity Logs vs Authentication Logs vs Campaign Logs.

Mumara records three distinct kinds of platform activity, each surfaced separately because the questions they answer are different. Knowing which log to open is half the investigation.

Authentication Logs

Sign-ins, sign-outs, password changes, 2FA enrolments. Who is on the platform, from where, how. The answer to 'did someone access the system?' Lives under Tools → Authentication Logs and is referenced on the Administrators page.

Activity Logs

Every mutation across the platform — create, edit, delete, schedule, configure. The answer to 'who changed this?' Tools → Activity Logs. The broadest of the three and the one most often consulted during incident investigation.

Campaign / Send Logs

Per-campaign send events — sent, delivered, bounced, opened, clicked, complained, unsubscribed — at the recipient level. The answer to 'what happened to this specific send?' Lives under the campaign reports, with the per-recipient drill-down.

Through an incident

From 'something is wrong' to 'here's exactly what happened'.

The flow every operator follows when they have a question about platform state. Each stop assumes only the previous step's output — no engineering, no SQL, no log-server access.

  1. Step 1

    See the signal

    A subscriber complains. A campaign sent twice. A sending node was deactivated. The first signal usually arrives from elsewhere — support ticket, dashboard graph, customer email. You start with a vague question.

  2. Step 2

    Filter the log

    Tools → Activity Logs. Filter by target type (Broadcasts, Contacts, Sending Nodes), by date window (last 24h, last 7d), by actor (which admin or user). Within seconds the result set is small enough to read.

  3. Step 3

    Trace the action

    The entry shows the action verb, the target (which broadcast, which contact, which node), the actor (which admin or token), the IP, the timestamp. You now know the what, the who, the when, and the from-where — every axis of the incident, at one glance.

  4. Step 4

    Export if needed

    For compliance review, security incident, or post-mortem documentation — export the filtered set as CSV. Attach to the ticket, pipe to your SIEM, or archive separately. The platform never deletes data you have already exported.

  5. Step 5

    Fix and re-prevent

    Knowing the action lets you fix the immediate problem (undo the delete, restore the segment, reactivate the node) and the structural one — adjust a role's permissions, enforce 2FA on the actor's role, tighten an API token's IP allowlist. The log becomes the source for the prevention plan.

Four ways Activity Logs earn their keep

One log surface. Every shape of buyer concern.

  • Security incident investigation

    Concern
    Something is wrong — a campaign that shouldn't have sent, a contact list that disappeared, a sending node that got reconfigured. You need to know who, what, and when, fast.
    What Activity Logs answer
    Filter by target type and time window. The mutation, the actor, the IP, the timestamp surface in seconds. Pair with Authentication Logs to confirm the actor was actually signed in from where you expected.

  • Compliance audit

    Concern
    An auditor asks for a chronological record of who modified contact data, who scheduled campaigns, who managed suppression. Standard SOC-2 / ISO-27001 evidence collection.
    What Activity Logs answer
    Filter by date range, export as CSV, attach to the audit ticket. The format is already the format auditors expect — actor + action + target + timestamp + IP. No data transformation needed.

  • Team accountability

    Concern
    Multiple admins on the same account. One of them made a mistake. The five-people-share-a-password failure mode is solved by per-admin accounts, but the question 'who did this' still comes up weekly.
    What Activity Logs answer
    Per-actor filter shows everything an admin did in a window. Coaching opportunity surfaces without finger-pointing — "I see you scheduled this broadcast at 11:08, here's what to do differently next time."

  • Handover documentation

    Concern
    A team member leaves. Someone new takes over a portfolio of broadcasts, drips, triggers. They need to understand what was configured by whom and why — the kind of context that lives in the previous person's head.
    What Activity Logs answer
    Filter by the departing admin's user ID over the lifetime of their tenure. The log becomes a chronological narrative of every decision they made on the platform. Hand it to the replacement as part of onboarding.

Common questions

What buyers usually ask.

What's the difference between Activity Logs and Authentication Logs?

Authentication Logs record sign-ins and sign-outs — when an admin or user got onto the platform and from where. Activity Logs record what they did once they were in. The two together give you the full story: Authentication Logs prove someone was signed in at 11:00 from IP 203.0.113.4; Activity Logs prove that at 11:08 the same person deleted a contact list. For most incident investigations you'll cross-reference both. Authentication Logs live on the [Administrators page](/campaigns/features/administrators/); Activity Logs are the broader audit surface this page is about.

What actions actually get logged?

Every mutation across the platform — Create, Update / Edit, Delete, Schedule, Send, Pause, Resume, Suppress, Unsuppress, Activate, Deactivate. Across every resource — Contacts, Lists, Custom Fields, Segments, Broadcasts, Drips, Triggers, Sending Nodes, Sending Domains, Bounce Addresses, Bounce Rules, Web Forms, Suppression entries, API Tokens, API Roles, Admin Roles, Administrators, Users. If it changes state on the platform, it lands in the log.

What does each log entry actually contain?

A consistent set of fields, plus a sometimes-attached payload. The core fields: action verb (CREATE / EDIT / DELETE etc.), target type + identifier (Broadcast: May Newsletter #38), actor (admin or user name + ID, or API token name + ID), IP address, timestamp. The payload (when relevant) is a JSON snapshot of what changed — useful for edits where you want to see the field-level diff. Read-only operations (just viewing a contact list) aren't logged because the volume would drown the audit trail.

How do API actions get attributed?

Every API call that mutates state is logged with the API token's identity as the actor — token name, token ID, and the role the token was acting under. If the same logical user has both an admin login and an API token, the two surfaces show as distinct actors in the log. This is the right behaviour for audit purposes — you want to see whether a contact was deleted by a person clicking in the UI or by a script using a token.

How long are logs retained?

Configurable per installation. Tools → Settings → Cron / Data Retention exposes the auto-deletion window. Common choices are 90 days, 180 days, 1 year, or longer per your data-retention policy and storage budget. For longer retention than the default, the simplest path is regular CSV export to your archive — the platform never deletes data you've already exported.

Can I filter and search the log?

Yes — multi-axis filtering. By actor (a specific admin, user, or API token). By action type (just deletes, just edits, etc.). By target type (just Broadcasts, just Contacts). By time window (today, last 24h, last 7d, custom range). The filters combine freely — "show me every DELETE that admin Marcus did against Contacts in the last week" is one click per axis. The result is paginated and exportable.

Does the log capture failed attempts too?

Activity Logs focus on successful mutations — what actually changed on the platform. For failed authentication attempts (login failures, 2FA mismatches), the Authentication Logs are the surface. For failed API requests (token revoked, rate-limited, permission denied) the API request logs are the surface. The boundary keeps each log searchable for its purpose — but in an incident investigation you'll often cross-reference them.

How does this integrate with my SIEM?

CSV export is the lowest-friction path — schedule a daily filter + export job and pipe the file into your SIEM's ingestion pipeline (Splunk, Datadog, Elastic, Sumo Logic, all support CSV ingestion). For real-time integration, the [Webhooks addon](/campaigns/addons/webhooks/) can fire on certain admin-action events, giving you an event stream your SIEM can consume directly. The platform doesn't ship a native syslog forwarder today — CSV + webhook is the supported pattern.

Are logs immutable?

Logs are write-only from the application layer — no UI mechanism to edit or delete individual entries. Auto-retention deletes the oldest entries based on the configured window, but you can't selectively delete an embarrassing entry. For installations under strict compliance (SOC-2 Type-2, financial services, healthcare), the recommended pattern is to export to your SIEM regularly so the SIEM becomes the immutable record of truth — the platform-side copy is then the working dataset.

Related

Pages that pair with this one.

Mumara Campaigns · Activity Logs

Every action recorded. Every question answerable.

Activity Logs ship with every Mumara Campaigns plan — Self-Hosted and Mumara Machine. Recorded by default, filterable by actor / action / target / time window, exportable as CSV, retained per your policy. The platform-side of the 'who did this' question, every time.

Get started See pricing