Using a “dead man's switch” to manage time-sensitive code

Question

In our software environment, we often run a/b tests, as is probably good practice. However, our environment is set up such that, in very short order, the code starts to become very crufty with dead tests. The testing registry is little more than a collection of internal wiki pages.

I thought of a "dead man's switch" style of defunct code management. If you're not familiar with the term, it refers to a switch that must be reset periodically in order to keep something from triggering -- in essence, if you don't responde, the switch triggers, and whatever you wanted the switch to trigger is performed.

For example, I would write some code, register it with this system in some way, and when a date of my predetermined choosing rolled around, I would get a notification that this code would be removed (automatically cleaned up) unless I intervened (manually clean up, or snooze).

What are the pros, cons and viability of incorporating such a system? Is it possible or wise? What might be some alternative ways to manage code against rotting?