← Insights

Operations

Issue tracking with an SLA clock

July 2026 · 6 min read

A project keeps three lists that everyone tries to merge into one, and the merge is where control quietly leaks away. Risks are things that might go wrong. Actions are things someone agreed to do. Issues are things that have already gone wrong and are hurting you right now. They look similar in a spreadsheet and they are managed completely differently, so the first rule of a good issue log is to know exactly what belongs on it.

Issues, risks and actions are not the same thing

An issue has happened. The integration is failing, the supplier missed the delivery, the environment is down. It is real, it is current, and the only question is how fast you close it. A risk has not happened - it is a possibility you are watching, weighing by likelihood and impact, and mitigating in advance. An action is a task with an owner and a due date, often raised to deal with a risk or an issue.

Mix them and the log loses its edge. Risks parked on the issue log make it look permanently on fire when nothing has actually broken. Issues filed as risks get "monitored" while the damage compounds. The discipline is simple: if it is already causing harm, it is an issue, and the clock is running. That last clause is what most logs get wrong.

The clock is the point

The reason an issue log needs a clock and a risk register does not is that issues are live damage. Every day an issue stays open is a day of cost, and "we will get to it" is not a plan when something is actively broken. So an issue log needs to answer one question the moment you open it: which of these is running late?

That is what a service-level target gives you. Set a target - say ten days to resolve - and let the log age every open issue against it. Age is just today minus the date raised. Compare age to the target and any open issue past it is a breach, and it should turn red on its own. Not because someone reviewed the list and decided it was late, but because the arithmetic says so. Late issues surface themselves instead of hiding three rows down in a list nobody re-reads to the bottom.

The breach flag changes the conversation. Without it, every stand-up starts by reading the whole log to work out what needs attention. With it, the red rows are the agenda and everything else can wait. You stop managing the list and start managing the exceptions.

Priority decides what the clock means

Not every issue deserves the same target, and a flat log pretends they do. A critical issue - production down, a customer blocked - is not in the same universe as a cosmetic defect, and treating them alike is how the important work waits behind the trivial. Priority is what lets you read the log properly: how many critical issues are open, how many high, and which priorities are breaching their targets.

The useful move is to break the open work down by priority with a visual weight to it, so the critical items surface first. A single critical breach matters more than a dozen low-priority issues sitting comfortably inside their target, and the log should show that at a glance rather than making you count.

Keeping the log honest

A few habits keep an issue log trustworthy, and trust is the whole game - a log people stop believing is a log people stop updating.

• Status is derived, not typed. Read Open or Resolved from whether a resolved date exists, so nobody has to remember to change a dropdown. A status you maintain by hand is stale by the next meeting.
• Root cause and fix live on the row. Record why the issue happened and what you did about it beside the issue itself. Now the log doubles as a problem-solving trail, and the next similar issue is faster to close because you can see how the last one went.
• Resolve-in-SLA is a metric worth watching. The share of issues closed inside their target tells you whether the team is keeping pace or slowly falling behind. A falling number is an early warning long before anyone feels overwhelmed.
• Review breaches first, always. If a stand-up only has ten minutes, it should spend them on the red rows. Everything green is, by definition, still inside the promise you made.

An issue log without a clock is just a list of complaints. Add a target, age every open issue against it, and let the breaches flag themselves - and the log starts telling you what to do instead of waiting to be read.

Get the boundary right - issues here, risks and actions elsewhere - and put a clock on it, and an issue log stops being a place work goes to be forgotten. It becomes the one page that tells you, honestly, whether you are keeping up.