How to document an operations runbook for your MU server

Every MU Online server eventually goes down at 3 a.m., crashes in the middle of a Castle Siege, or corrupts a record after an update. In those moments, the difference between a 10-minute hiccup and a 6-hour disaster isn't how much you know — it's how fast the right information reaches the hands of whoever is at the keyboard, which is often not you. A runbook is the document that carries that operational knowledge out of your head: direct, tested procedures that a competent person can follow under pressure without calling you. This tutorial shows how to structure, write, and maintain an operations runbook for a MU server, with a ready-made template to adapt. The service names, paths, and schedules used here are examples and vary by provider/version of your emulator and your infrastructure.

Prerequisites

Documenting operations assumes there are operations to document — that is, a running server whose procedures you already carry out, even if only from memory. If the server doesn't exist yet, build it first by following how to create a MU Online server and come back to document it. To write a good runbook you need:

• Practical knowledge of your current operations: how you restart, back up, run an event, restore a record. The runbook formalizes what you already do, so you need to do it well before documenting it.
• A place accessible from outside the server to store the document: a Git repository, a wiki, a cloud document. If the runbook only lives inside the VPS and the VPS goes down, you've lost your runbook exactly when you need it most.
• Access to the contact details and credentials the procedures will reference — without putting passwords in the runbook (those go in a separate vault).
• The willingness to test each procedure after writing it. A step you "think works" cannot go into the runbook.

What a MU runbook needs to cover

A runbook isn't free-form writing; it's a predictable structure. Someone in a panic needs to find the procedure in seconds. The table below shows the essential sections of a MU server runbook and what each one answers. The exact breakdown is an example and varies by provider/version and by the size of your team.

The most common mistake is starting with the "Overview" and never reaching the procedures. Flip it: write the routine and incident procedures first, since those are the ones that save the server. The overview can come later.

Step 1 — Define the header and metadata

Every runbook begins with information about itself. This isn't bureaucracy: it's what lets you trust (or distrust) the content. At the top of the document:

# Operations Runbook — ViciadosMU Server

- **Version:** 3.2
- **Last revised:** 2026-07-09
- **Document owner:** Gabriel
- **Environment:** Production (Windows Server VPS, example)
- **Emulator/Season:** (fill in here — varies by provider/version)

> This document is operational. Each procedure has a trigger,
> numbered steps, and an expected result. Secrets do NOT belong here.

The last-revised date is the single most important field in the whole runbook. A two-year-old procedure can be dangerously wrong, and the date warns the reader to check before trusting it blindly.

Step 2 — Map the architecture on one page

Before the procedures, the reader needs to know what the server is made of. Don't write a treatise — a one-page map is enough. List the components, where they run, and what they depend on:

## Architecture (example — varies by provider/version)

Components and startup order:

1. Database (SQL Server) — port 1433 — the foundation of everything
2. DataServer — depends on the database
3. ConnectServer — port 44405 (example) — server list
4. JoinServer — bridge between Connect and Game
5. GameServer(s) — port 55901 (example) — the game world
6. Website/web panel — depends on the database

Paths:
- Server:   D:\MuServer\
- Backups:  D:\Backups\
- Scripts:  D:\Scripts\
- Logs:     D:\MuServer\*\Logs\

Even a simple text diagram helps a lot for someone who has never seen the structure. The critical detail here is the startup order: anyone who brings up the components out of order generates connection errors that are hard to diagnose.

Step 3 — Write the routine procedures

This is the heart of the runbook. Each procedure follows the same format: a title with the trigger, numbered steps, and an expected result. Here's an example of a restart procedure:

### PROC-01 — Restart the GameServer

**When to use:** GameServer frozen, general lag, high memory usage,
or a scheduled restart.

**Impact:** all players drop for ~1-2 minutes. Avoid during
events (Castle Siege, invasions).

**Steps:**
1. Announce on Discord/chat that there will be a restart in X minutes.
2. Connect to the VPS via RDP.
3. Open the folder D:\MuServer\GameServer\
4. Close the GameServer window (or run Stop-Process).
5. Wait 5 seconds.
6. Run GameServer.exe (or run D:\Scripts\RestartGameServer.ps1).
7. Confirm in the console that the server loaded the maps without errors.

**Expected result:** GameServer online, players can log in,
console with no error messages in red.

**If it fails:** see PROC-08 (GameServer won't start).

Notice what makes this procedure work under pressure: the when to use makes the trigger clear, the impact stops someone from restarting in the middle of a Castle Siege, the numbered steps leave no doubt, and the if it fails chains to the recovery procedure. Write all your routine procedures in this format: start everything, stop everything, manual backup, run an event, add an item, create a GM account.

Step 4 — Write the incident procedures

Incidents are routine procedures turned upside down: instead of "I want to restart," it's "something broke, what do I do?". The key is to start with the symptom, because that's what the operator observes. Example:

### PROC-08 — GameServer won't start / crashes on launch

**Symptom:** GameServer closes by itself on launch, or the console shows
a connection error with the database/DataServer.

**Quick diagnosis (in this order):**
1. Is the database up? (check the SQL Server service)
2. Is the DataServer running? (must start BEFORE the GameServer)
3. Are the ports free? (another process may have locked the port)
4. Is there disk space? (a full disk brings everything down)
5. Does the GameServer log point to which file/connection failed?

**Actions by cause:**
- Database down → start SQL Server, then PROC-02 (start everything)
- DataServer down → start DataServer, wait, start GameServer
- Port locked → identify the PID with netstat, kill the process
- Disk full → PROC-11 (emergency log cleanup)

**Escalate to:** the admin on duty, if not resolved after 15 min.

A good incident procedure turns panic into a checklist. Instead of "it won't start, now what?", the operator follows the quick diagnosis in order and reaches the cause. Document the incidents that have already happened to you — those are the most valuable, because they'll happen again.

Step 5 — Quick reference and contacts

Close the runbook with the information you'll look up constantly: ports, paths, frequent commands, and the contact chain. Here, a compact table does fit:

## Quick reference (example — varies by provider/version)

| Component      | Port   | Path                           |
|----------------|--------|--------------------------------|
| SQL Server     | 1433   | (Windows service)              |
| ConnectServer  | 44405  | D:\MuServer\ConnectServer\     |
| GameServer     | 55901  | D:\MuServer\GameServer\        |

## Contacts and escalation
1. GM on duty — handles routine and minor incidents
2. Technical admin (Gabriel) — infrastructure incidents
3. Project owner — business decisions (rollback, long maintenance)

## Where the secrets are
- Passwords and keys: the team's password manager (NOT here)
- VPS access: vault X, entry "Production VPS"

The escalation chain prevents the worst incident scenario: everyone assuming someone else is handling it, and no one handling it. Make it clear who does what and at what point things get escalated.

How to test whether the runbook actually works

An untested runbook is fiction. The test is simple and merciless: ask someone on the team who has never carried out that procedure to follow it, alone, using only the text, while you watch in silence. Every time the person hesitates, asks a question, or makes a mistake, you've found a hole in the runbook. Note it and fix it. Do this at least for the critical procedures: restart, start everything, restore backup.

The second test is the real-incident test. The next time something breaks, resist the urge to fix it from memory: open the runbook and follow the procedure. If it led you to the solution, great. If not, you've just discovered what's missing from the documentation — fix it while the incident is still fresh in your mind.

Common errors and fixes

The mistake of keeping the runbook only inside the server is treacherous because it only shows up at the worst possible moment: the server went down, and with it the document that would teach you how to bring it back up. Redundancy here isn't a luxury, it's the bare minimum.

Launch checklist

• Runbook stored in a location accessible from outside the server
• Header with version, revision date, and owner filled in
• Architecture mapped on one page, with startup order
• Routine procedures written (start, stop, restart, backup)
• Incident procedures written, starting with the symptom
• Each procedure with a trigger, numbered steps, and expected result
• Quick-reference table (ports, paths, commands)
• Contact and escalation chain defined
• No secrets written in the document; only a reference to the vault
• Critical procedures tested by someone who didn't know them
• Numbered table of contents at the top for quick lookup
• Agreed revision cadence (e.g., monthly review of critical procedures)
• Team informed of where the runbook lives and how to use it

With the runbook in place, your MU server stops depending exclusively on you. Operations become a process the team can follow, incidents stop being improvised, and knowledge stops dying in your memory. It's the document that turns a one-person project into one that survives the absence of any single person — including you.

Frequently asked questions