Troubleshooting
I installed the app and nothing appeared on my issues
Expected. Jira keeps app panels hidden until somebody opens one, and this is the most common reason a working installation looks broken.
- First, confirm the install from the sidebar.
Open Apps in the Jira sidebar. Runphase is listed under Your apps and expands into All runs, In flight and Records. If it is there, the install worked and only the issue panel is missing.
- On an issue, look for the Runphase button in the action row under the title, beside Create subtask. With several apps installed it may sit under an Apps button there.
- Click it once. Jira remembers the panel for that issue from then on, for everyone who views it.
- Administrators can turn it on everywhere: open the panel once, then use Show for all work items from the panel's own menu. Only administrators see that option.
My colleague cannot see the panel on an issue I can
The Runphase button requires edit permission on the issue. Someone with view-only access will not see it until a person with edit permission has opened the panel on that issue, after which it is visible to everyone viewing it.
This only affects the panel. The full page does not need anyone's permission to appear: a read-only viewer reaches it from Apps → Runphase in the sidebar and can read every run they are allowed to see. The dashboard gadget works regardless of issue permissions too.
A run shows an old name for the change
Working as intended, and it cannot be corrected from Runphase.
A run takes a copy of the Jira issue's summary at the moment it is created, and keeps it. Renaming the issue afterwards does not change the run, because the record is meant to say what the change was called when it was executed, not what it was renamed to later.
If a run was created against a placeholder or a typo and has not been executed yet, create a fresh run on a correctly named issue. Once a run has closed, the name is part of an immutable record and stays as it is.
A template I saved is not in the list
Almost always permissions, working as intended.
A template is offered to people who could see the Jira change it was saved from. If the person looking cannot read that issue, the template is not shown to them, and they are told it was not found rather than that it exists but is barred, because a template's name can disclose a change on its own.
- Check whether the person can open the original Jira issue. If not, that is the answer.
- Check you are looking at a run in
DRAFT. Templates apply to a draft plan; a frozen or closed run has nothing to replace. - If the list shows an error rather than being empty, Jira could not be reached to answer the permission question. The list says so and offers a retry. Templates are never quietly hidden on an error.
Something said "not found" and I expected it to work
Runphase gives the same answer for "this does not exist" and "you may not see this", deliberately. Distinguishing them would leak the existence of changes people cannot read.
Two different messages are worth telling apart when you ask for help:
- "Issue … was not found": the app could not confirm you can see that Jira issue.
- "Run … was not found": the issue was fine; there is no such run.
Quote the message exactly when you write in. It identifies which check refused.
A run will not close as verified
Close run requires every required success criterion to have passed. Completing all the steps is not enough. That is the whole point of the separation.
- Open the Verify screen and check
Criteria verified.
Any criterion still
pendingblocks a verified close. - Mark each one you have proved with Mark this criterion passed.
- If the change genuinely did not work, close the run honestly instead, with Mark failed or Initiate rollback. A recorded failure is worth more than a run left open.
I need to change something in a closed run
You cannot, and that is deliberate. A record that can be quietly corrected afterwards is not a record. Terminal states are immutable for everybody, including the person who created the run.
The one exception is removing sensitive data that should never have been entered. Use Remove this value from the record, which is audited rather than silent: the record shows that a redaction happened. See removing something that should not be in a record.
If the plan was wrong, the right move is a new run with the correct plan. The old record stays as the account of what actually happened.
Runphase did not answer / failed to load
The panel, the full page and the gadget all lead with a sentence rather than a raw error, and offer a retry where one makes sense.
- Use the retry control if one is offered. Transient network failures and rate limits recover on their own.
- Reload the Jira page.
- Check whether Jira itself is healthy. Runphase runs inside Jira on Atlassian infrastructure, so a Jira incident takes it with it.
- If it persists, send the diagnostic text that trails the message. It is there to be quoted.
I pasted a password into a plan
Take it out of the record with Remove this value from the record, then rotate the credential. Assume it was seen.
Avoid the situation where you can: reference where a credential lives rather than quoting it. Steps, notes and deviations are free text, and a closed record is immutable, so a redaction afterwards is the only remedy.
Asking for help
Write to support@runphase.com. First response within one business day. These five things turn a two-day exchange into one reply:
- Your Jira site URL.
- The run or issue key involved.
- What you expected, and what happened instead.
- Roughly when, with a timezone. This is what makes it findable in the logs.
- The exact text of any error message.
Please do not send credentials, API tokens or personal data. Nothing about diagnosing a Runphase problem needs them.