While that would be understandable if this were a simple unix-style tool that did one thing and only one thing, the reality is that this service does way too much stuff.

• Fetches CB every 5 minutes (or less!)
• Updates DB
• Updates LHoCB (from DB)
• Acts as a CB client when you telnet into it (WTF???) - if this is active, then the fetcher can get to be much more frequent.

I generally have one or two socket clients connected to the service at all times, so restarting the service daily would mean that those windows wouldn't have the history going back through the night (or whenever I restarted it). So I'm loathe to restart it willy-nilly.

If I were to redesign it now, I would separate these things out into pieces. The fetcher/sender would feed a pub-sub service (possibly redis). The DB-updater would be a separate process to push into the database. The update of LHoCB would be a cron job (read from db, send to perlmonks). The CB client would also listen to the pub-sub service. (Note that the CB stats already is a separate cron job.) And then your suggestion would make a lot of sense (in fact, if the fetcher and sender were separate, I could just throw it into a cron job, but then I wouldn't be able to dynamically increase the frequency of fetches based on CB usage). But I'm never going to do all that. So I'm going to live within what I've got until such a time as I grow bored of worrying about it or perlmonks itself dies.