How to implement an admin action audit log on your MU Online server

MU Online servers with a team of Game Masters and administrators need something many neglect until it goes wrong: a reliable audit log of every administrative action performed. When an extremely high-value item appears out of nowhere, when an account is banned without clear justification, or when a GM abuses spawn commands, the only way to investigate accurately is to have an immutable record of who did what, when, and with what parameters. This tutorial shows how to structure this system, from capturing GM commands to secure storage and querying the records.

Why an audit log is indispensable

Without an audit log, any investigation into administrative abuse turns into "his word against theirs" — the administrator has no way to prove what happened, and the affected player has no way to contest an unfair decision. Beyond the trust aspect with the community, the audit log also protects the GM team itself: an honest administrator unjustly accused of abuse can prove their innocence by showing the exact record of the actions taken. On servers with a large team, this system also helps identify patterns of excessive command usage by a specific GM before it becomes a bigger problem.

What should be logged

Log table structure in the database

A common approach is to create a dedicated table, separate from the game tables, to store audit records:

CREATE TABLE admin_audit_log (
    id BIGINT IDENTITY(1,1) PRIMARY KEY,
    admin_account VARCHAR(50) NOT NULL,
    admin_ip VARCHAR(45) NULL,
    action_type VARCHAR(50) NOT NULL,
    target_account VARCHAR(50) NULL,
    target_character VARCHAR(50) NULL,
    command_raw VARCHAR(500) NULL,
    previous_value VARCHAR(500) NULL,
    new_value VARCHAR(500) NULL,
    reason VARCHAR(500) NULL,
    created_at DATETIME NOT NULL DEFAULT GETDATE()
);

This structure covers both in-game commands and web panel actions, as long as both systems write to this same table (or to mirrored tables with a compatible format for unified querying).

Capturing GM commands on the GameServer

Most emulators process GM commands through a central function that parses the text typed in chat (something like HandleGMCommand or equivalent). The ideal interception point is right after permission validation and before (or right after) execution, to ensure only commands that were actually accepted and executed get logged — avoiding cluttering the log with invalid attempts, which can be handled in a separate "denied attempts" log.

[GMCommand] Received: /additem 14 6 13 255 255 0 0
[GMCommand] Authorized for account: GMADMIN01
[Audit] INSERT admin_audit_log (action_type='ADD_ITEM', admin_account='GMADMIN01', command_raw='/additem 14 6 13 255 255 0 0', target_character='PlayerX', created_at=NOW())

Capturing actions from the web admin panel

On the web panel side (usually PHP, Node.js, or similar), every sensitive admin route should call a central audit function before confirming the action to the user. A simplified PHP example:

function logAdminAction($adminAccount, $actionType, $targetAccount, $reason = null) {
    $stmt = $pdo->prepare(
        "INSERT INTO admin_audit_log (admin_account, admin_ip, action_type, target_account, reason, created_at)
         VALUES (?, ?, ?, ?, ?, NOW())"
    );
    $stmt->execute([$adminAccount, $_SERVER['REMOTE_ADDR'], $actionType, $targetAccount, $reason]);
}

// Usage on the ban route
logAdminAction($_SESSION['admin_user'], 'BAN_ACCOUNT', $targetAccount, $_POST['ban_reason']);

Every irreversible or sensitive action (ban, balance edit, character deletion) should require a reason to be filled in before it executes — this dramatically improves the quality of records for future investigations.

Permissions and protection against tampering

The database user used by the GameServer and the web panel to insert logs should have INSERT-only permission on the audit table, never UPDATE or DELETE. This prevents a GM with database command access (or an attacker who compromises a GM account) from erasing their own trail. Ideally, deleting old records (within the retention policy) should be handled by a separate administrative process, run only by the system's root administrator, with the cleanup itself logged at an even higher level.

Querying and analyzing the logs

A simple query panel, with filters by admin account, action type, affected account, and date range, already handles most investigations. For larger servers, it's worth considering automatic alerts: for example, notifying leadership when the same GM executes an unusual volume of item commands in a short time, or when a high-impact action (bulk-adding Zen) is executed outside that administrator's normal activity hours.

Retention and archiving policy

Define an active retention period (for example, 90 to 180 days) during which logs remain fully accessible for quick queries, and an archiving process for older records, moving them to compressed storage instead of deleting them. This keeps the main log table performant for day-to-day queries, without losing the complete history for investigations involving older events.

Best practices for communicating with the team

An audit system only works well if the GM team knows it exists and understands its purpose as mutual protection, not hostile surveillance. Communicating this clearly when onboarding new administrators, and reinforcing that the reason for every sensitive action must be filled in honestly, builds a culture of accountability that reduces abuse before any investigation is even needed.

Common errors and fixes

Audit log implementation checklist

• Audit table created and separated from the game tables.
• In-game GM commands captured and recorded in the log.
• Web admin panel actions also recorded in the same system.
• Database account restricted to INSERT on the log table.
• Reason field mandatory for sensitive actions.
• Retention and archiving policy defined and documented.
• Query panel with basic filters available to leadership.

With the audit log in place, your administrative team gains a layer of accountability that protects both players and the GMs themselves, and the natural next step is reviewing the server's other security and general configuration practices in the MU Online server creation tutorial.

Frequently asked questions