Runphase

Runphase is an Atlassian Forge app for executing a planned change against the Jira issue it already lives on. You write the procedure before the window opens, work through it step by step while the change is happening, and are left with a record of what was actually done.

A change request is straightforward to authorize and difficult to execute well. Jira records the decision thoroughly: who asked, who approved, when it was scheduled. It records much less about the window itself: which steps ran and in what order, which success criteria actually held, where the plan was departed from and why, and whether anyone could reconstruct that afterwards when asked.

That gap is what this app is for.

The shape of a run

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.

A run is created from a Jira issue and moves through a fixed state machine. Terminal states are immutable: a finished run is a record, not a document that keeps changing. The reference has the states and what each one allows.

What it does

An ordered runbook with a current step. The procedure is written while there is time to think about it, then frozen when the run goes ready. During the window there is one current step, so there is never a question about where the change has got to.

Success criteria, kept separate from the steps. A completed runbook does not mean the change worked. Steps are what the engineer does; criteria are how the engineer proves it. A run reaches VERIFIED only once every required criterion has passed.

Rollback as a first-class object, not a paragraph. A run carries its rollback trigger, an ordered rollback procedure and an optional expected recovery time, and rollback readiness stays visible for the whole active window. Starting one takes explicit confirmation and switches the run into a focused rollback state.

Deviations, recorded rather than tidied away. When reality departs from the plan, the departure is appended: the step it happened on, when, who, what happened and what was done about it. The original planned sequence is never rewritten, so the record shows both what was planned and what occurred.

An immutable run record. A closed run becomes a calm, read-only account: the issue, the owner, the planned window against the actual one, the duration, the outcome, the timeline, the deviations, the verification results, whether rollback was used, and who took part.

Templates. A procedure worth repeating can be saved and applied to a later run. Templates are snapshots, so editing one never rewrites a past record, and a template is usable by anyone who could see the Jira change it was saved from.

Where it lives in Jira

Runphase renders in three places, and none of them is a separate application to keep in another tab:

• A full page, where runs are created, listed and read, in the Jira sidebar under Apps → Runphase, split into all runs, what is in flight, and the closed records.
• An issue panel on the change itself, summarising that one run without anyone leaving the issue.
• A dashboard gadget showing what is in flight now and how the last 30 days closed.

New to it? Getting started takes one change all the way through, and explains why the issue panel needs one click before it appears.

What it does not do

Worth saying plainly, because it is the reason the app can make the guarantees below.

Runphase records execution. It does not perform it, and it does not govern it. It holds no credentials to your infrastructure, runs nothing on your behalf, and reaches out to nothing. Approvals, risk scoring, CAB, freeze periods and sign-off happen before the window and belong in Jira. What happens between "start" and "closed" is what this app is about.

Where your data goes

Nowhere. Each line here is checkable rather than asserted:

• No egress. The app's manifest declares no remotes and no external permissions, so it is structurally unable to make a network request outside Atlassian. No analytics, no telemetry, no error reporting, no third-party processor.
• Runs on Atlassian. Atlassian reports every deployment as eligible. Compute and storage are Atlassian's, data residency follows the host product, and eligibility is monitored continuously rather than self-declared.
• Read-only on Jira. There is no write scope. Runphase never creates, edits, transitions or comments on an issue. A change executed through it leaves the underlying Jira issue untouched.
• Four permission scopes, and no others. read:jira-work, read:jira-user, storage:app and report:personal-data. Each is justified on the Marketplace listing and in the privacy policy.
• No vendor-side copy. Everything the app keeps lives in Forge app storage, scoped to your installation. Skram Systems operates no database, no dashboard and no export, and cannot read your data.

Getting it

FILL: Marketplace listing URL. The listing is not live yet. Replace this paragraph with the install link and remove the placeholder.

Questions before then go to support@runphase.com.