Coming in a bit late into the debate, but what the hell..

A lot of my work looks like this too. Here are some rules of thumb I have come up with.

• Get to know Getopt::Std or Getopt::Mixed, in order to drive your scripts with command-line switches.
• One of those switches, especially from cronnable jobs, is "shut the fu%$ up" so that you don't get mail filling your inbox. If something does go wrong and you want to send mail alerts, use Mail::Sendmail and make your own report. When cron sends the unexpected output of a job it invariably lacks context to help you determine what blew up.
• Write everything to a datestamped log file (this has already been mentioned).
• Count the records, items, iterations, and print out "where you are" every n loops, such that you print something out every 10 seconds or so. That way it's easy to glance at a running script and determine if its wedged. Something like
  

      my $count = 0;
      while( 1 ) {
          print "\t$count\n" unless ++$count % 100_000;
      }
  [download]

  and maybe add a few different state variables in there too.
• In your log and/or results files, delimit things with tabs. Don't use commas or spaces, because they crop up far too often in real data and then it becomes a bear to parse downstream. Using tabs lets you hand the logfile to an end-user who can import it in Excel with no difficulty should they need to do their own processing on it.
• Open your logfile in a BEGIN clause and close it in an END clause. This way even if you die you have a chance to scribble some last minute items into the logile.

HTH