If it’s rare and the impact is low, then it’s not getting prioritized. It doesn’t matter how much time passes if you decide not to spend time investigating.

You are either seriously naive, or have never worked on any large and complex legacy codebase.

I’ve been living in a bubble with my .NET day-job, where debugging/tracing/postmortems are a breeze. Compare with, say, a CORBA or DCOM system, deployed to prod with uber-optimized binaries without any debugging-symbols.

So it’s not that I haven’t worked on large-scale, complex legacy systems - but that I haven’t worked on any large-scale, complex legacy systems written in languages bereft of runtime reflection and verbose error reporting.

—————

It’s also possible that the bug was never found because its impact was so minimal: e.g. 1 crash per year, each causing 3 minutes’ downtime in a noncritical system: that’s something that will never get investigated fully.

Sorry but I don't buy it, any crash can be found and fix by one or more humans, if it was not it's either they're incompetent ( I doubt that ) or they did not beleive it was important enough to fix.

A crash is actually the easiest kind of problem to fix since you have a crash. It means stacktrace, core dump, kernel error etc..