A slightly different form of deadlock detector can still be really useful for portions of the system that are not unbounded network IO. I agree that predicting

A slightly different form of deadlock detector can still be really useful for portions of the system that are not unbounded network IO. I agree that predicting forward progress from in-memory state like Haskell seems to be doing is more or less useless in the presence of IO. But you can instead use some measure of forward progress and a simple long timeout (like 10-60 seconds) to empirically determine the system is stalled. E.g., you might reasonably implement timeouts on slow network clients or otherwise have a way to idle them, so it is still a problem if the system does not make forward progress in 10 seconds or whatever. Or if your service manages all access to disk, you can expect bounded IO from disks that have not failed. Then you can take some debugging action (development) or maybe restart the service (prod) or some combination of the above when a deadlock is detected in an empirical way (no forward progress in a time period).