Operations Runbook Generator

A runbook is a set of documented procedures that define what to do in specific operational situations, startup, normal operation, incidents, and shutdown. In OMS operations, a runbook tells the operations team how to start the OMS and verify its state, how to run reconciliation and investigate breaks, how to recover from outages, and how to close down at end-of-day. A good runbook can be executed by any trained operator regardless of whether the primary OMS expert is available.

Tier 1 breaks are small quantity or price discrepancies that the operations team resolves independently within the current trading day, without escalating to portfolio management or risk. Tier 2 breaks exceed the quantity or market value thresholds you configured and require escalation, the portfolio management team must be informed because the position error may affect active trading decisions, and the risk team must be informed because the unresolved discrepancy represents unquantified exposure.

For OMS systems that use event sourcing (writing each order event to a persistent log before processing it), recovery after an outage means replaying events from the log rather than relying on the in-memory state at the time of the crash. This guarantees that no events are lost and the OMS state is deterministic, the same events always produce the same result. Without event-log replay, fills received during the outage window may be missed, causing position breaks that can persist all day. See the Deterministic Recovery guide for full details.

Runbooks should be reviewed at minimum annually and after any material system change, a new broker connection, a new trading strategy type, an OMS version upgrade, or a regulatory change affecting recordkeeping requirements. The review should be conducted by both operations staff (who execute the runbook) and technology staff (who maintain the systems). Runbooks that go unreviewed for more than 18 months often contain obsolete host names, outdated contact information, or missing steps for new system components.

This tool generates an illustrative framework for educational purposes. Before using any part of it in a regulated trading environment, it must be reviewed and approved by your compliance team, technology staff, and operations management. Regulatory requirements vary by firm type, registration, and jurisdiction. The placeholder citations in the output are accurate as of the tool's knowledge date but should be verified against current regulatory text before inclusion in official procedures.

It produces the structure and the standard procedural content for startup, intraday reconciliation, break escalation, outage recovery, and end-of-day, shaped by the answers given. What it cannot supply is anything specific to a particular environment: hostnames, dashboard locations, named contacts and their escalation order, counterparty support arrangements, and the thresholds an organization has actually agreed. The output is a scaffold that removes the blank page rather than a finished document.

No. The generation runs in the browser on the page itself using only what is entered, and nothing is transmitted or stored between visits. That matters because runbook inputs describe operational architecture, which is information most organizations would not paste into a remote service. It also means the output has to be copied out before leaving the page, since reloading discards both the answers and the generated document.

By walking through each procedure against the real system, ideally as an exercise rather than during an incident. The test is whether someone who was not involved in writing it can follow each step and reach the described outcome, which reliably exposes assumed knowledge, missing access, and steps that no longer match the system. Recording the date of the last walkthrough on the document itself makes staleness visible.

The runbook says what to do; the incident record captures what was actually done, when, and by whom; the review compares the two. That comparison is the main source of runbook improvements, because the places where the procedure was abandoned or improvised are exactly where it was wrong or incomplete. Treating each incident as an input to the next revision keeps the document connected to how the system actually fails rather than to how it was expected to.