Troubleshooting

Nearly always, the job is fine and the ping is not. Work down this list in order — it is roughly how often each one turns out to be the cause.

The ping never arrives

Check the ping works at all

Run it by hand from the machine the job runs on:

curl -v -m 10 "https://api.rippler.io/ping/<pingID>/"

If the monitor updates, the URL and the network are fine and the problem is in how the job invokes it — carry on down this page. If it does not, the response says why: success: false with Monitor not found means the pingID is wrong, usually a truncated copy or a missing trailing slash.

The line is in /etc/crontab

The snippets Rippler shows are user crontab lines: five schedule fields and then the command. /etc/crontab is a different format — it takes a user column between the schedule and the command.

# user crontab, via `crontab -e`
0 3 * * * curl -fsS -m 10 -o /dev/null "https://api.rippler.io/ping/<pingID>/"

# /etc/crontab — note the `root`
0 3 * * * root curl -fsS -m 10 -o /dev/null "https://api.rippler.io/ping/<pingID>/"

Paste a user-format line into /etc/crontab and cron reads curl as the username, rejects it, and ignores the entire file — including every other job that was already in it. It logs the reason and carries on silently:

Error: bad username; while reading /etc/crontab
(*system*) ERROR (Syntax error, this crontab file will be ignored)

Check with journalctl -u cron | tail or grep CRON /var/log/syslog | tail. The simplest fix is to put the line in your own crontab with crontab -e, where the format the snippet uses is the correct one.

The job runs, but cron cannot find curl

Cron runs with a minimal environment, and its PATH is often just /usr/bin:/bin. If the command works in your shell and not under cron, use an absolute path (/usr/bin/curl), or set PATH at the top of the crontab.

The same applies to the job itself: a script that relies on your shell profile will not find its interpreter or its environment under cron.

The % in a crontab line

Cron treats % specially — everything after an unescaped one becomes standard input to the command. If a ping URL or a date format in your line contains %, escape it as \%.

Outbound HTTPS is blocked

A locked-down host may not be able to reach api.rippler.io at all. curl -v above will show it hanging or refused. That is a firewall or egress rule, not Rippler.

It alerts when nothing is wrong

• The ping arrives, just late. Raise the grace duration to a little above the job's worst normal run time. Grace exists for exactly this.
• The job fails occasionally and fixes itself. Raise failure tolerance so it takes several failures in a row to notify. The monitor still shows down in the app; only the notification waits.
• The schedule in Rippler does not match the real one. The monitor's schedule is what Rippler expects, not what the machine does. If they disagree, the machine wins and Rippler alerts. Check the expression against the next expected times shown beside it.
• Time zones. A cron expression is interpreted in the monitor's own zone, which the schedule summary states. The next-run times are shown in yours.

No alert arrived

• Alert emails may be off for you. It is a per-person setting on your profile. The team members list shows who has it off.
• The outage may not have reached your failure tolerance yet. Below the threshold nothing is sent — and no recovery message is sent either, since there was no alarm to clear.
• Check the address. Send a failure ping by hand and watch what arrives; it is worth doing once, deliberately, before you need it.

Durations look wrong

• Sixty times too long or too short usually means a duration reported in minutes. ?duration= is in seconds.
• Overlapping runs get mixed up when the closing ping has no run id. A job that runs every minute and sometimes takes three interleaves its starts and ends; pass the same ?rid= on both pings and they cannot be confused.
• No duration at all means the run had no /start/, or the start ping was lost. A close with no open is still recorded as a success — just without a measured duration.

Uptime looks too low

A monitor counts as unmeasured until its first ping, so a new monitor shows no percentage rather than 0%. Paused time is excluded the same way. If the number still looks wrong, check the 90-day strip: it shows the worst status seen on each day, so one bad day is visible even when the percentage is not.