When a mongod, which is part of a replica set, cannot recover because the oplog has rolled over, the mongod node stays in the RECOVERING state. There is no way to tell the difference between a node in RECOVERING that is actively applying oplog and will eventually transition to SECONDARY, and one that is in RECOVERING due to being too stale and will never recover unless a node becomes available that has an overlap with its oplog.

Currently the only way to get this is through the logs, which keeps tools like ops/cloud manager from easily detecting and alerting when a node falls off the back of all available sync source oplogs.