A strong answer. “Four times in two months while meeting SLA is the important detail, because it means the current incentives are working exactly as designed — we are being measured on restoration and we are restoring well, so nothing forces a fix. That is the thing to change.

Practically: I would quantify it rather than describe it. Four incidents, the engineering hours consumed each time, the customer impact, and the cumulative cost against the estimated cost of the permanent fix. That comparison is usually stark and it is what moves a backlog item that has been deprioritised four times.

Then I would find out why it has not been fixed, because in my experience it is rarely that nobody knows the cause. Usually the fix belongs to a team with different priorities, or it requires a change to something nobody owns, or the workaround is cheap enough that it never reaches the top of a queue. Those are three different problems with three different escalations.

I would also stop the automatic restore from being invisible. If a runbook silently fixes it at 3am, the organisation never feels the cost. I would make the recurrence visible in the monthly report as its own line rather than as four separate incidents that each closed green.

And in the meantime I would improve detection and reduce the restore time, because those are mine to control — but I would be explicit that this is mitigation, not resolution, so nobody mistakes the improved numbers for the problem going away.”