The blast radius of a bug has nothing to do with how small it is or how long it ran. It depends on whether the code wrote anything.
A bug on the read path limits itself. Someone sees a wrong number, you ship the fix, the wrong number is gone. The damage and the bug have the same lifetime.
A bug on the write path outlives its own fix. The deploy stops the production of bad rows. It does not retract them. And by then those rows have been read by everything that treats stored state as truth: a ledger line, an attribution match, a payout batch, a notification already sent to a user, a reconciliation report someone has already signed off.
So during an incident the question I care about is not how long the bad code was live. It is this: can I enumerate what it produced?
That is why in payment work I keep money-affecting writes append-only, with the input that produced each line stored right next to it. A wrong entry gets corrected by a compensating entry, not by an UPDATE nobody can audit afterwards. And every derived write carries enough provenance that I can ask which code path produced which rows between two deploys.
If you cannot run that query, you cannot bound the damage. You can only guess at it, and then you are negotiating with a customer about a balance you cannot reconstruct.
Most severity scales I see rank bugs by what the code does. The more useful axis, I think, is how long its output survives.
And if you run systems that move money, that is the thing worth checking today: when a bad write ships, whether you can currently identify the exact set of records it created...