Documentation

Runphase takes a change that Jira has already approved and gives you somewhere to actually run it.

A run is attached to one Jira issue. You write the procedure before the window opens, work through it step by step while the change is happening, prove it worked, and are left with a record nobody can quietly edit afterwards.

  1. PrepareImpact, preflight, the runbook, the criteria and the rollback, written before the window opens.
  2. ExecuteOne current step at a time, with rollback one click away for the whole window.
  3. VerifyA finished runbook is not success. Every required criterion has to pass.
  4. RecordWhat was planned, what happened, and the evidence. Closed, and not editable.

Those four words are the whole product. Each is a screen, and a run moves through them in order.

Start here

The three places Runphase appears

None of them is a separate application to keep open in another tab.

WhereWhat it is for
Full page
Apps → Runphase in the sidebar
Creating runs, listing them, and reading closed records. This is the main surface. It sits in the Jira sidebar under Apps and expands into All runs, In flight and Records. See getting started.
Issue panel
the Runphase button on an issue
The run for the change you are looking at, on the issue itself, with a link through to the full page. Hidden until someone with edit permission opens it once on that issue. See getting started.
Dashboard gadget
Runphase change activity
What is in flight now, and how the last 30 days closed. For people watching rather than executing.

If you only read one thing

Steps and success criteria are not the same. Steps are what you do. Criteria are how you prove it worked.

Finishing every step does not close a run successfully. A run becomes VERIFIED only once every required criterion has passed. This catches the change that went exactly to plan and still broke something, which is the case a checklist alone cannot express.