Reliability tips
Make sure pings arrive, and that a ping problem never breaks the job it's watching.
This page covers how to send pings so they reliably reach FlatLyne, without the ping ever slowing down or failing your real job. The snippets use curl; Examples shows the same ideas in other languages and schedulers.
Always set a timeout
A ping is a tiny request, but the network between your server and FlatLyne can still stall. Without a timeout, a stalled ping can hold up your job, or keep a cron slot busy, for minutes. Many HTTP clients have no overall timeout by default, including curl, Python's urllib and requests, and Go's http.Client.
Set one on every ping. curl -m 10 gives up on an attempt after 10 seconds. FlatLyne's server itself gives up on any request it can't read or answer within 10 seconds, so there's no point in waiting much longer than that.
Retry transient failures
A single dropped packet or a brief network blip shouldn't turn into a false alert. --retry 5 makes curl try again after timeouts and after HTTP 408, 429, 500, 502, 503 and 504 responses, waiting longer between each try.
curl -fsS -m 10 --retry 5 -o /dev/null \
https://api.flatlyne.com/CSps9LOZGccsl2o7ieL0_YrQyZJtkGK_0H1u30FJ-NIWith wget, use -T 10 -t 5 for the same effect: a 10-second timeout and 5 tries in total.
Each check accepts 3 pings per minute
FlatLyne accepts up to 3 pings per check per minute. Further pings in that minute get a 429 response and aren't recorded. A run that sends a start ping and a finish ping uses 2 of the 3, so don't run a job with start pings more than once a minute on the same check.
Never let a ping fail the job
How you join the ping to your command decides what happens when either one fails:
| Pattern | When the job fails | When the ping fails |
|---|---|---|
backup.sh && curl ... | No ping is sent. FlatLyne alerts once the check's grace period runs out. | The cron line exits non-zero, so cron may email you. The job's own work is already done. |
backup.sh; curl .../$? | The non-zero exit code marks the check as failed straight away. | Same as above. |
curl ... || true | Doesn't apply on its own; combine it with one of the patterns above. | The failure is ignored, and your script carries on. |
Add || true after every ping in a script that uses set -e. Without it, a network problem on the start ping stops the script before the real work runs.
Ignoring a ping failure is safe: if the ping never arrives, FlatLyne notices the missing ping and alerts you. A broken ping produces a false alarm, never a silent miss.
Ping at the start and at the end
Send a /start ping before the work and the result after it. The check's page then shows how long each run took, and a run that started but never finished stands out as a start ping with nothing after it.
This wrapper does both, keeps the job's exit status, and never lets a ping change it:
#!/bin/sh
PING_URL=$(cat /etc/flatlyne/backup-db-nightly.url)
curl -fsS -m 10 --retry 5 -o /dev/null "$PING_URL/start" || true
/usr/local/bin/backup.sh
status=$?
curl -fsS -m 10 --retry 5 -o /dev/null "$PING_URL/$status" || true
exit $statusSee Failures, exit codes and start pings for how FlatLyne treats each of these pings.
Keep ping URLs secret
The ping URL is the credential: anyone who has it can send pings to your check, marking it as up when it isn't or as failed when it's fine. Treat it like a password:
- Keep it in a secret store (a Kubernetes Secret, a GitHub Actions secret, or a file only the job's user can read) rather than in your repository.
- Keep it out of crontab lines if cron emails you. Cron puts the command in the email subject, URL included. The wrapper above reads the URL from a file instead.
- Don't print it in job logs.
A ping URL that's wrong, revoked or expired gets a plain 404, with no detail about which. If a ping that used to work starts getting 404, check the URL against the one on your check's page. On Pro and Business you can regenerate a check's ping URL from its page, and the old one then gets 404 immediately. On Free, keeping it private is your main protection. See Ping URLs and Ping keys for more on each kind of URL.
Your server's clock doesn't matter
FlatLyne timestamps every ping with its own clock when the ping arrives, and works out when the next ping is due from that same clock. Your server's clock never enters into it, so a host with a drifting clock still records accurate ping times.
Clock drift can still make cron start your job at the wrong real-world time, though, which can make a ping arrive early or late. Keep NTP running on your servers, and let the check's grace period absorb small differences. See Schedules.
Firewalls and proxies
Pings need outbound HTTPS to api.flatlyne.com on port 443. FlatLyne doesn't publish a list of IP addresses, so allow the hostname rather than an IP range, for example through an HTTP proxy or a DNS-aware firewall rule.
If your servers reach the internet through a proxy, curl and wget both read the https_proxy environment variable:
https_proxy=http://proxy.internal.example.com:3128
0 2 * * * /usr/local/bin/backup-with-pings.sh