Issue Log Template: Give Every Blocker an Owner and a Next Step
Download an issue log template with a completed example, priority rules, review questions, and a closure checklist that separates fixes from workarounds.
An issue log records problems that have already happened, the work they affect, and the actions needed to resolve them. A useful entry has an owner, a next step, and a check that establishes whether the problem is actually fixed. “Waiting for someone” is a status description, not a plan.
Download the editable issue log. The text file contains a reusable issue record, a completed example, and review and closure checklists. Use it in a shared document or transfer the fields to the system your team already uses.
Our rule: do not collect more detail than the team can maintain, but never remove the fields that tell someone what to do next.
What should you record for each issue?
Capture the observable problem, its consequence, its owner, the next action, and the evidence needed to close it. Keep the description factual enough that a person outside the conversation can understand why intervention is needed.
| Field | Useful content |
|---|---|
| Identifier and date | A stable reference and when the issue was reported |
| Observed problem | What happened, where, and under what conditions |
| Impact | Which current commitment or user task is affected |
| Priority and reason | Why it needs attention in this order |
| Owner | The person coordinating resolution |
| Next action | A specific step and the person performing it |
| Due or review date | When action or a new decision is required |
| Status | Where the issue is in the resolution process |
| Closure evidence | What would prove resolution, and who will check |
Atlassian's issue log template uses description, priority, status, and owner as core information. The additional next-action and closure fields here turn that record into a working conversation rather than an inventory of complaints.
Avoid putting passwords, personal records, or restricted incident details into a broadly shared log. Link to the appropriate protected record when the team only needs to know the operational effect and who is handling it.
For a small project, one shared document may be sufficient. Choose the location people will check consistently; a sophisticated tracker nobody opens is less useful than a short log that drives decisions.
What does a completed issue look like?
Describe the failure, its consequence, and the next verifiable action. Separate a workaround that helps people now from the permanent change needed to prevent the same problem recurring.
The following example is fictional and shows the format rather than a real incident.
Issue I-07 — welcome-message expense link does not open.
Reported: Friday morning, after a new starter followed the link in the welcome message.
Observation: the message points to an old document location. A new starter sees an access error; an existing operations user can still open the old location.
Impact: the new starter cannot find the approved expense instructions from the welcome message. The FAQ publication commitment is therefore not fully met.
Priority: address before the next welcome message is sent. The immediate need is access to correct instructions, not redesigning the whole onboarding experience.
Owner: Morgan coordinates the fix. Lee confirms the approved document location, and Casey can approve a change to the welcome message.
Immediate action: Morgan supplies the current approved instructions through the existing authorized channel while the link is corrected.
Permanent action: update the welcome-message link after Lee confirms the location and the intended audience's access.
Review point: check progress before the next scheduled welcome message. If access remains unresolved, Casey decides whether to hold that message or use an approved alternative.
Closure evidence: a person with the same access level as a new starter can open the replacement link and locate the submission instructions. Morgan records the test result; Casey confirms acceptance.
“Works on my account” would not close this issue. The original failure depended on the user's permissions, so the check must address that condition.
The workaround also does not prove the permanent fix. Keep both visible so short-term relief does not make the underlying problem disappear from the team's attention.
How do you prioritize without making everything urgent?
Prioritize by the effect on the current commitment and the time available to act. The loudest requester or oldest entry should not automatically outrank a problem that will block a release tomorrow.
For each issue, ask:
- Who cannot do what they need to do?
- What committed outcome is affected?
- Is there a safe, acceptable workaround?
- When does delay remove a useful option?
- Who can make the necessary trade-off?
Use a small set of priority labels with definitions your team understands. For example, “before next release” is more informative than “high” when nobody has agreed what high means.
Do not invent percentage risk scores for an event that has already occurred. Describe the current effect and the plausible consequences of leaving it unresolved. If the problem also reveals a future risk elsewhere, record that separately with a link.
The Jira issue log guidance connects ownership and prioritization with tracking work through to completion. Your particular labels can differ, but the team should be able to explain why one item moves ahead of another.
If resolution requires changing the agreed scope, timing, or resources, use the authorized change process. A blocker does not automatically grant its owner permission to alter everyone else's commitments.
How do you run a short issue review?
Review changed facts, blocked actions, approaching dates, and decisions that need an authorized owner. Do not spend the meeting reading unchanged descriptions aloud while the people who can resolve them wait.
Work through the log in this order:
- Check whether any new issue threatens an immediate commitment.
- Ask owners what changed since the last review.
- Replace vague next actions with concrete steps.
- Resolve or escalate decisions that the owner cannot make.
- Verify items proposed for closure.
An escalation should contain a decision request. “Please advise” is weak; “Approve the alternate document location or hold Monday's welcome message” tells the decision-maker what needs settling.
Use the communication plan to identify who needs a meaningful update. Keep the detailed log linked from the weekly status report, rather than copying every issue into a second document that soon drifts out of date.
Suggested states are open, in progress, waiting, resolved awaiting check, and closed. These are our working labels, not an official standard. Define “waiting” carefully: name what is awaited, who can supply it, and when you will follow up.
When can you close an issue?
Close an issue when the agreed evidence demonstrates resolution, or when an authorized person explicitly accepts a remaining limitation. Keep the difference visible; accepting an unresolved limitation is not the same as fixing it.
Record the action taken, the verification result, the person who accepted it, and the closure date. Where a workaround remains in place, name its owner and the condition that will trigger another review.
The UC Berkeley toolkit keeps issue management alongside other project controls. Treat the log as part of delivery history: it can explain why a schedule changed or why a different approach was chosen.
If the same issue keeps returning, use the lessons learned template to decide what process should change. Reopening the same problem with a new identifier can hide the pattern.
Finally, choose which resolution actions belong in today's work. Do Only 3 Things a Day offers a way to define a few concrete outcomes and protect time for them. The goal is to handle genuine blockers without letting every new irritation erase the entire plan.
Frequently asked questions
What is the difference between an issue and a risk?
An issue is an existing problem; a risk concerns uncertainty about something that could happen. If a risk materializes, record the actual problem and link the records rather than losing its history.
Can a text document be an issue log?
Yes, if the team can find the current version, assign owners, and track changes. A shared table or document can work for a small project. More complex work may need filtering, notifications, or access controls.
Who owns an issue another team must fix?
Name someone to coordinate resolution and follow-up, while separately identifying the person or team performing the fix. Coordination ownership does not imply authority over that team's work or responsibility for causing the problem.
Should closed issues be deleted?
Usually retain them in an archive or closed view, subject to your organization's retention rules. Their resolution history can prevent repeated investigation and help explain past delivery decisions.