EDIT: Found the article again: https://spectrum.ieee.org/automaton/aerospace/robotic-explor...
I'm not sure where I got the reboot thing from, I think HN in a thread after the Perseverance landing
Does it try to keep state across such a reboot? Is the first course of action to try to deduce whether it's about to crash? Is every sensor reading done multiple times to reduce risk of reading wrong (typically, such sensors are basic and doesn't employ error checks or such)? Does it try to understand why the OS crashed and do any graceful degradation, eg "fine, don't use that sensor then"?
That might miss bit flips that don't affect the flight profile, but those do not need a real time response. Bit flips in collected data for example could probably be found afterwards when the data is analyzed.
Heck, it might even make sense to figure out what the minimum time, T, is such that something can go wrong that a reboot will fix fast enough to save the mission but only if the reboot happens within T seconds of the onset of the problem. Then just reboot every T seconds regardless of whether you know of something actually wrong.