How to Monitor Cron Jobs in Ruby
Version managers put Ruby somewhere cron cannot find it. That is the first thing to fix, before any monitoring.
Monitoring a Ruby script under cron is straightforward once the script runs at all, and getting it to run is where most of the time goes. Version managers are the reason.
Fix the interpreter path first
rbenv and rvm work by manipulating PATH in your shell profile. Cron does not load your shell profile, so under cron there is no ruby, no bundle, and no gems.
The failure is immediate and looks like nothing happened, because the error goes to cron's mail and cron's mail goes nowhere.
An alternative that survives an rbenv version change is to wrap the command in a login shell, which does load the profile. It is slower and more fragile, and it is the right choice when the Ruby version changes often.
Test your crontab line by running it through env -i, which strips the environment down to roughly what cron gives you. If it works there, it will work under cron.
Vixie cron sets PATH to little more than /usr/bin:/bin unless you override it. Neither .rbenv/shims nor .rvm/bin is in there, which is the whole reason the script that runs fine in your terminal does nothing at 02:00.
ensure and at_exit
Ruby's ensure runs on exception and on normal completion, which makes it a natural home for the ping. at_exit goes further and runs even when the process is terminating, which covers exit! and most signals.
Note the abort on a zero count. abort raises SystemExit, which is not a StandardError, so it exits with a non-zero status without being swallowed by the rescue. If you want it to ping as a failure, rescue Exception instead, carefully.
The whenever gem writes the crontab, once
whenever generates crontab entries from config/schedule.rb. The generation happens when you run whenever --update-crontab, usually as a Capistrano deploy hook.
If that hook is missing, or the deploy user differs from the user whose crontab was written, your schedule.rb is a description of jobs that are not installed. The file looks right in code review and nothing runs.
whenever also has a job_type mechanism, which is the cleanest place to standardise monitoring across every job rather than editing each one.
Bundler needs the right directory
bundle exec resolves the Gemfile from the current working directory upward. Without the cd, it either finds a different Gemfile or none, and you get a Could not locate Gemfile error into a log nobody reads.
Set BUNDLE_GEMFILE explicitly if the job runs from somewhere other than the app root.
Related guides
Rails applications have more options, covered in monitoring cron jobs in Rails.