Issue log template
An issue log is a list of problems that have already happened and need fixing: who reported each one and when, how urgent it is, who is dealing with it, the workaround in the meantime, the cause and fix, and when it was closed. This free Excel template also counts how many days each issue has been open, or took to close.
Running a company of 30 to 200 people? Documents like this are now worth money.
Use it wherever problems arrive faster than they can be fixed: after a system goes live, during a move to new premises, or in a team that handles internal requests. It's narrower and more detailed than a RAID log: issues only, from first report to confirmed fix.
What's in the template
The download has three sheets: the blank issue log with 100 rows, an example and a read-me. Besides the columns below, each row records who reported the issue, the area affected, the workaround, the resolution (cause and fix) and the date closed.
From the Example sheet, a fictional 40-person garden products company in its first weeks with a new online shop:
| Ref | Reported | Issue: what's happening | Priority | Owner | Status | Days open |
|---|---|---|---|---|---|---|
| I‑001 | 7 Sep 2026 | Discount codes can't be applied at checkout on mobile phones | Critical | Agency lead developer | Closed | 1 |
| I‑002 | 7 Sep 2026 | Orders to Highlands and Islands postcodes charged standard delivery | High | E-commerce manager | Closed | 3 |
| I‑003 | 8 Sep 2026 | Card payments reach the bank two days later than with the old shop | Low | Finance manager | Closed | 1 |
| I‑004 | 9 Sep 2026 | Some order confirmation emails land in customers' junk folders | High | IT lead | Fixing | counting |
| I‑005 | 14 Sep 2026 | Website stock levels don't update after the overnight sync | Critical | Agency lead developer | Investigating | counting |
| I‑006 | 16 Sep 2026 | Newsletter sign-up box missing from the new site | Low | E-commerce manager | Waiting on others | counting |
| I‑007 | 17 Sep 2026 | Plant care pages slow to load on mobile | New | counting |
Closed issues show how long they took; open ones keep counting. In the workbook, Critical shows red and High amber, a New status shows amber until someone triages it, and Closed turns green.
How to run an issue log
- Decide what goes in and who adds it. Problems only: something broken, wrong or blocking work.
- Log it the day it's reported: what's happening, who's affected, and how to make it happen again if it comes and goes.
- Triage quickly, for example by the end of the same working day. Triage means a priority, one owner and a status other than New.
- Put a workaround in place for anything Critical or High, and write it in the log so everyone uses the same one.
- Review the list on a schedule: daily during a go-live, weekly once things settle. Sort by Days open to find the ones that have gone quiet.
- Close only when the reporter confirms the fix, with the cause and fix recorded. Until then it's Resolved.
- Read the closed issues once a month. A cause that keeps turning up points to a process that needs changing.
Setting priorities
Agree the definitions before the first issue arrives, or everything ends up Critical. These are the read-me sheet's definitions, with example response times:
| Priority | Means | Example response |
|---|---|---|
| Critical | Work has stopped, or customers are affected now | Owner starts straight away; workaround the same day |
| High | Serious, with no good workaround | Started within a working day |
| Medium | There's a workaround people can live with for now | Scheduled within the week |
| Low | Minor or cosmetic | Fixed when convenient, or batched |
Change the response times to suit your team; what matters is that everyone who triages uses the same written definitions.
Issue log vs RAID log
A RAID log is a project management summary: risks, assumptions, issues and dependencies in one register, reviewed weekly by the project team. An issue log is a working tool for getting through problems one at a time, with the detail a RAID log leaves out: triage, workaround, cause and fix, and days open.
Many projects keep both, with the RAID log carrying only the few issues that threaten the plan. If fixing an issue needs more time or money than the plan allows, raise a change request.
Example: the first weeks of a new online shop
The example sheet follows a fictional 40-person garden products company after it launched a new online shop. Three things in it are worth copying:
- Critical issues got a same-day workaround. When mobile customers couldn't use discount codes, customer service took those orders by phone until the fix went in the next day.
- Not every issue is a fault. Slower card payments turned out to be the new provider's payout cycle; the issue was closed with that explanation and the cash flow forecast updated.
- Untriaged issues stand out. The newest report is still New, with no priority or owner, and stays highlighted until someone picks it up.
Common mistakes
- Using it as a wish list. Feature requests and "it would be nice if" items bury the real problems.
- Everything marked Critical, so priority stops meaning anything.
- Shared ownership. "IT" or "the agency" isn't an owner; a named person at the agency is.
- Closing on the fixer's word. If the fix didn't work, the problem comes back as a new row and its history is split across two.
- No workaround written down, so customers get a different answer from each person they ask.
- Deleting closed rows. They're your record of what went wrong, how long fixes took and which causes keep coming back.
Frequently asked questions
What's the difference between an issue and a risk?
An issue has already happened and needs action now. A risk might happen, and is managed in advance by reducing its likelihood or its impact. Risks belong in a risk register or a RAID log, not in the issue log.
How is days open calculated?
For a closed issue, it's the date closed minus the date reported. For an open one, it's today's date minus the date reported, so the number rises each day until the issue is closed. It counts calendar days, weekends included.
Can I use it as a simple helpdesk tracker?
Yes, for a small team handling internal problems, such as an office manager fielding IT and facilities faults. Once you're logging dozens of issues a day, a ticketing system will serve you better.