Free Issue Log Template — Excel Download

01 — What's Included

What's in the Template — 10 Columns Explained

The Issue Log is a single-sheet Excel file with a violet branded header, project metadata row and 50 pre-formatted issue entries. Three columns — Category, Priority and Status — use validated drop-downs to keep the log filterable and consistent.

Column	Field	Notes
ID	Issue Number	Pre-filled ISS-001 to ISS-050. Extend by copying the last row. The ID links this log entry to any associated change requests or action items.
Date Raised	Date	When the issue was first formally raised — not when it was first noticed. Entering it in the log is the act of raising it formally.
Issue Description	What the issue is	A clear, specific description. State the problem, its current impact and what is at risk if it is not resolved. Avoid vague entries like "system issue" — be specific enough that someone unfamiliar with the project can understand it.
Category	Drop-down	Technical / Resource / Schedule / Budget / Scope / External / Other. Validated drop-down — use to filter by type for reporting or root cause analysis.
Priority	Drop-down	Critical / High / Medium / Low. Set based on the impact on project baselines and the urgency of resolution required. See the priority guide below.
Status	Drop-down	Open / In Progress / Escalated / Resolved / Closed. Use Escalated when the issue has been formally raised above the PM's authority for resolution.
Raised By	Name	Who identified and raised the issue. Not necessarily the person responsible for resolving it.
Owner	Name	The single person accountable for driving resolution. One name only. If the issue requires escalation, the owner is the PM until a senior owner formally accepts it.
Resolution	What was done	How the issue was resolved — the specific action taken. Only complete when the issue is Resolved or Closed. This column is what makes a good issue log genuinely useful for lessons learned.
Date Closed	Date	When resolution was confirmed and verified. An issue is not closed because the owner says they have fixed it — it is closed when the PM confirms the fix is working and the impact has been removed.

💡

The Resolution column is the most valuable field in the log. Most issue logs track problems but never record how they were solved. A completed Resolution column is a searchable knowledge base — when a similar problem surfaces on a future project, the team can search the log and find what worked last time. Fill it in every time, even for minor issues.

02 — Priority Guide

How to Set Issue Priority — The Four Levels

Priority determines how quickly an issue needs a response and how much management attention it receives. Use these definitions consistently across the project team so that "High" means the same thing to everyone.

🔴

Critical

Blocking progress or threatening project viability. Immediate escalation required.

Response: Same day

🟠

High

Significant impact on cost, schedule or scope. Sponsor notification needed.

Response: Within 2 days

🟡

Medium

Manageable impact. Needs resolution within the current reporting period.

Response: Within 1 week

🟢

Low

Minor inconvenience. Track and resolve as capacity allows.

Response: Within 2 weeks

Priority Can Change — Review It Every Meeting

A Medium issue that is not resolved in two weeks may become High. A High issue that blocks a critical path task may become Critical. Priority is not a static field — review it at every project meeting and update it if the situation has changed. An issue that appears to be improving can also be downgraded — this shows the log is being actively managed, not just maintained as a record.

📌

Don't over-use Critical. When everything is Critical, nothing is. A log where 40% of issues are flagged Critical loses its prioritisation signal entirely. Reserve Critical for issues that are genuinely blocking work or threatening the project. If your team uses it too liberally, reset the definition at the next team meeting with the examples above as anchors.

03 — Status Lifecycle

Issue Status — From Open to Closed

The Status drop-down has five options. Each represents a distinct stage in the issue lifecycle. Understanding when to use each — and the difference between Resolved and Closed — prevents issues being marked complete before they really are.

Open

Just raised, not yet assigned

→

In Progress

Owner working on resolution

→

Escalated

Above PM authority

→

Resolved

Fix applied, monitoring

→

Closed

Verified complete

Resolved vs Closed — an Important Distinction

Resolved means the fix has been applied and the owner believes the issue is no longer active. Closed means the PM has verified independently that the resolution is working and the issue impact has been removed. This distinction matters: an owner may mark a technical issue as Resolved after applying a patch, but if the system is still experiencing the same problem, it should remain Resolved — not Closed — until the PM confirms it is fixed.

Never let owners close their own issues. The PM (or a designated quality reviewer) should always be the one who moves status from Resolved to Closed, having confirmed the resolution is effective.

04 — Issue vs Risk

Issues, Risks and Actions — Keeping the Registers Clear

Three registers work together during project execution. Understanding the boundaries between them keeps each one clean and useful.

Dimension	Issue Log	Risk Register	Action Tracker
What it records	Problems that have occurred and need resolving	Uncertain future events that might affect the project	Tasks committed by someone to someone by a date
Tense	Present — happening now	Future — may or may not happen	Future — will be done by a date
Trigger to create entry	A problem has occurred and is affecting the project	An uncertainty is identified that could affect the project	A commitment is made in a meeting or decision
Closed when	Resolution verified effective by PM	Risk has passed, been mitigated or materialised (becomes issue)	Task completed and output verified
Link between registers	A risk that materialises → moves to the issue log. An issue resolution decision → logged in the decision log. An issue or risk → generates action items in the action tracker.

⚠️

Issue Log

Now — Active Problems

Something has already gone wrong. Needs an owner, a resolution plan and monitoring until closed.

🎲

Risk Register

Future — Potential Problems

Something might go wrong. Needs probability, impact and a mitigation or contingency plan.

✅

Action Tracker

Commitments — Tasks to Do

Someone committed to do something by a date. Needs a single owner, a specific output and a deadline.

05 — FAQ

Issue Log — 4 Common Questions

An issue log (also called an issue register) records all problems, concerns or obstacles that have occurred on a project and require resolution. Unlike a risk register which tracks things that might happen, an issue log tracks things that have already happened. Each entry records the issue description, category, priority, who raised it, who owns resolution, the current status and the final resolution. It is reviewed at every project meeting until all issues are closed.

A risk is an uncertain future event — something that might happen. An issue is something that has already happened and is currently affecting the project. In project management, risks are tracked in a risk register and issues are tracked in an issue log. When a risk event occurs, the risk is typically moved from the risk register to the issue log and managed as an active problem. This distinction is tested on the PMP exam — the PMBOK defines issues as risks that have materialised.

Issues are prioritised by combining two factors: the severity of the impact on project baselines (cost, schedule, scope, quality) and the urgency of the required response. Critical issues are blocking progress or threatening viability — same-day response required. High priority issues significantly impact one or more baselines — resolve within 2 days. Medium priority issues have manageable impact — resolve within 1 week. Low priority issues are minor — resolve within 2 weeks as capacity allows. Review priorities at every project meeting, as a stalled Medium issue can quickly become High.

Escalate an issue when: the PM does not have the authority or resources to resolve it; it has been open beyond the agreed resolution time without progress; it threatens a key milestone or the project's viability; its impact has grown beyond the original assessment; or the owner is genuinely blocked and cannot progress without senior intervention. Escalation is not a failure — it is the PM doing their job correctly by surfacing problems that need senior attention. The issue remains in the log with status changed to Escalated until a resolution path is agreed.

Free Issue Log Template Excel Download