Hello,
I thought about a(n admittedly jerry-rigged) solution against the debug command flooding the router.
Assume I can only telnet or SSH into the device, and want to issue the debug command. First, I’d open a second telnet or SSH session, check which vty line I’m in, and configure that vty line with the command no terminal monitor. I’d then issue the debug command, and if it makes any inputs from my first session impossible, I’d issue the undebug all command in the second window (which wouldn’t be flooded by the debug command’s outputs, because earlier I issued the no terminal monitor command on its vty line).
The Kron option is more elegant, but I’m curious: would this work? 
I guess there are some devices that are so old, they don’t support the Kron option (Cisco IOS XE Release 2.1 was released around May 4, 2008 if I’m not mistaken: https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/2/xe_2_1_newfeatlist.html , and the other IOS versions are also from around that time period, so I guess devices before 2008 don’t have the Kron option).
If the CPU gets completely overwhelmed, maybe both the elegant Kron solution and my makeshift attempt would both fail.
Of course, if the IOS supports it, it would make more sense to use the Kron command, because at least that way, even if you forget to issue the undebug all command, the system will do it for you. But I’d use my makeshift solution along with the Kron command, just in case I make a mistake when issuing the Kron command - provided the makeshift solution actually works. I’d also issue the Kron command to reenable the terminal monitor option on the second vty session an hour or two later, in case I forget to do so manually.
Have a nice day.
Attila