Why a change log is non-negotiable for an MSP
A single Sikurd account can reach into dozens of customer phone systems and change them. That reach is the point of a fleet tool — but it raises a question every MSP eventually has to answer, usually under pressure: "A client's call routing broke at 2 p.m. Who touched it, and what did they change?"If the honest answer is "we're not sure," you don't have a management platform; you have a shared root password with a nicer UI.
Accountability is also a trust story you tell outward. When a customer asks "did someone on your team change our after-hours rule last week?" the difference between "let me check the log" and "let me ask around" is the difference between a vendor who is in control and one who is hoping. Sikurd treats the change history as a first-class record: every operator-initiated change to every customer PBX is captured, attributed, and searchable. This post walks exactly what that means in the product — no more, no less.
What lands in the log
The audit log is wired into the mutating operations across the portal. When a change goes through Sikurd, it writes an event. The catalog is broad and concrete — among the recorded event types:
- Extensions & users — added, removed, modified; greetings uploaded.
- Configuration — fleet parameter pushes and individual setting changes; trunks, queues, ring groups, digital receptionists, and departments edited or deleted; prompts uploaded, assigned, or deleted.
- Updates — update channel changed, an update scheduled, installed, or failed.
- Maintenance — maintenance started/ended, windows created/deleted, and purges.
- Instance lifecycle — instance created, connected, re-authenticated, address and notification-email changes, status pages created/updated, credentials saved/cleared, license refreshed, and instance deleted.
- Alerts & self-healing — alerts acknowledged, muted, resolved, and auto-resolved; whitelisted services auto-restarted.
- Account security — password-reset requests and completions, and the second-factor events that pair with SSO & MFA (a failed MFA challenge, a single-use recovery code being spent).
The shape of a single record
Each entry stores the same backbone: the event type, a human-readable description, the timestamp, the tenant (the MSP), and — when the change targets a specific PBX — the instance. The instance's name is snapshotted onto the row at write time, a small but deliberate choice: if that PBX is later removed from your fleet, its history doesn't turn into a wall of orphaned IDs. The entry still reads "Acme HQ ," so the trail of "who decommissioned this site" survives the site going away.
Beyond the backbone, each row carries a structured metadata blob. For a parameter push, that blob records the parameter name, the value it was set to, and — crucially — the previous value, plus whether the entry was newly created or an actual change. That's a literal before-and-after, captured at the moment of the change, not reconstructed after the fact.
Always attributable: a person, or "System"
A log of changes with no names is just a rumor with timestamps. So Sikurd resolves the acting user into a readable label — Jane Doe <jane@msp.com>, falling back to email, then name, then the raw ID so the row always renders something, even for a since-deleted user — and stores it on the entry. The viewer shows "by Jane Doe" under each change.
Just as important is honesty about the changes no human made. Sikurd's monitoring does real work on its own: an alert can auto-resolve on the next polling cycle, and a whitelisted service can be auto-restarted by self-healing. Those events are written with a dedicated "System"actor sentinel, so they render as "by System" rather than being silently pinned on whoever happened to be logged in. When you're reading the log during an incident, you can tell at a glance what your team did versus what the platform did.
One trail, the right people, the right filters
The history is meant to be used, not just stored. Sikurd surfaces it in three places, gated by role:
- Per-instance feed. On an instance's page, an Audit Log panel shows that PBX's history with quick filter pills (Extensions, Config, Updates, Maintenance, Alerts, Version) and paged loading. A general Member sees this for the instances they have access to.
- Tenant-wide feed. A single feed across every instance in your account, including the orphaned entries from deleted instances. Because it exposes every user's actions across the whole fleet, it's restricted to Owner, Admin, and Super Admin.
- Master view (Super Admin). A cross-tenant table, newest first, with tenant, event-type, timeframe (24 hours / 7 / 30 / 90 days / all time), and free-text search over the description, event, and instance name — with pagination.
Two scope notes, stated plainly so there's no over-promise. First, the audit log is an internal tool: it does not appear on the public Customer Status Page, which is built to show clients health, uptime, backups, and incidents — not your team's change history. Second, while most entries are tied to a specific instance, the log is scoped to the tenantfirst; tenant-level actions that aren't tied to one PBX (such as an MFA recovery code being used) are recorded against the tenant with no instance attached. You can pull one customer's history or the whole fleet's from the same place.
Append-only — and what that does and doesn't mean
The portal offers no way to edit or delete an audit entry. There is no "clear history" button, no bulk-delete, no admin override to rewrite a row. Entries are only ever appended. In day-to-day terms, that means the record an operator leaves behind is the record that stays.
We're careful not to oversell this. The audit log is a standard, append-only database log — its integrity rests on the fact that the application never exposes a mutation path, not on a cryptographic proof. That is a real and useful property, but it is a different thing from the verified-backup restore certificates, which are cryptographically hash-based and tamper-evident by design, with a public verification page. If you need a math-grade "this artifact has not been altered" guarantee, that's the restore certificate's job. The audit log's job is different and complementary: a complete, attributed, searchable account of who did what, and when.
How it fits the "prove you're in control" story
The audit log is one leg of a three-legged stool. SSO & MFA control who can ever hold a session and how they prove it's really them. Verified backups prove that what you'd restore actually restores. The audit log closes the loop in the middle: a continuous record of what changed once someone was inside. Together they let you answer the three questions a serious customer — or your own change-management process — will eventually ask: who got in, how did they authenticate, and what did they touch?
For dispute resolution, that trail is the calm answer to a tense question. For change management, it's the difference between policy and proof. And like everything else on Sikurd, it isn't an enterprise add-on or a locked tier — there are no tiers. The audit log is included for every account; you simply pay per instance beyond your first three, which are free forever. Being able to say "here's exactly what we changed, and when" shouldn't be the upsell. It should be the default.