Rails Cron Job Monitoring

The problem

Rails apps lean on scheduled work — nightly database backups, data migrations, cache warmers, report exports, and Sidekiq-cron or whenever-gem tasks. Most of it fails silently. A `rake db:backup` task can raise, exit non-zero, and disappear into a log file nobody reads. The crontab line that whenever generated can vanish after a Capistrano deploy that didn't run `whenever --update-crontab`. A long-running migration can hang for hours while your dashboards stay green. Uptime monitoring doesn't catch any of this: the web server is up, the database is up, but the job that was supposed to run at 2 AM never did — and you only find out when a customer asks where their export is. Cron jobs are not servers. "Up/Down" logic does not tell you whether a scheduled job actually ran, ran on time, finished within its expected window, or reported success.

How Pakyas helps

Pakyas uses execution-signal monitoring: each Rails job tells Pakyas when it starts, when it finishes, and whether it succeeded or failed — signals emitted by the job itself. Because Pakyas knows each task's intent and schedule, it distinguishes the failure modes that matter for Rails work. It flags a job as Missing when it stops signaling (a deploy dropped the crontab entry, or the box never woke up), Late when it starts past its expected window, Overrunning when a migration or backup blows past its expected duration, and Error when the job runs and explicitly reports a failure. Silence is treated as Missing, not as success — so a whenever task that quietly stopped firing won't sit behind a green dashboard. One curl appended to your existing command is all the instrumentation a job needs; no gem, no agent, no changes to your Rails code.

Set it up

1. 1

   Create a check and copy its ping URL

   # In the Pakyas dashboard, create a check for your job
   # (e.g. "Nightly DB Backup"), set its expected schedule and
   # grace period, then copy the check's ping URL:
   #
   #   https://ping.pakyas.com/{public_id}
   #
   # {public_id} is the check's UUID shown on its detail page.
   # Success (default):  https://ping.pakyas.com/{public_id}
   # Start signal:       https://ping.pakyas.com/{public_id}/start
   # Failure signal:     https://ping.pakyas.com/{public_id}/fail

   No /ping/ path prefix — the public_id goes directly after the host.

2. 2

   Wrap the job in your whenever schedule (config/schedule.rb)

   # config/schedule.rb
   set :output, "log/cron.log"
   
   PING_URL = "https://ping.pakyas.com/PUBLIC_ID"
   
   every 1.day, at: "2:00 am" do
     # Signal start, run the task, signal success — or signal fail on any error.
     command "curl -fsS #{PING_URL}/start && " \
             "bin/rails db:backup && " \
             "curl -fsS #{PING_URL} || " \
             "curl -fsS #{PING_URL}/fail"
   end

   Replace PUBLIC_ID with your check's UUID. -fsS makes curl fail quietly on errors but still print server-side problems.

3. 3

   Regenerate the crontab and verify it deployed

   # Locally or in your deploy hook:
   bundle exec whenever --update-crontab
   
   # Confirm the entry is actually installed:
   crontab -l
   
   # If you deploy with Capistrano, ensure the
   # capistrano-whenever gem runs --update-crontab on each deploy
   # so the entry is never silently dropped (check your deploy config).

   A missed --update-crontab is the most common cause of a Rails cron job going Missing after a deploy. Pakyas will alert you when that happens.

Pricing

Start free — the Free tier covers 10 checks at $0, enough to monitor every scheduled task in a small Rails app. Paid tiers scale up: Developer at $9/mo, Pro at $29/mo, and Business at $99/mo.

See the full breakdown on the pricing page.