Ping API
Every signal a job can send, over GET, POST or HEAD, and how Cronwize answers.
Signals
Every signal works over GET, POST and HEAD.
| Request | Meaning |
|---|---|
https://ping.cronwize.com/{key} | Success |
https://ping.cronwize.com/{key}/start | A run started |
https://ping.cronwize.com/{key}/fail | The run failed: the monitor goes down at once |
https://ping.cronwize.com/{key}/{0-255} | Exit status: 0 is success, anything else is a failure |
The exit status form lets one line report either outcome:
backup.sh; curl -fsS -m 10 https://ping.cronwize.com/YOUR-KEY/$?Responses
| Status | Body | Meaning |
|---|---|---|
200 | OK | Stored |
404 | Unknown key | |
429 | Rate-limited: more than 60 accepted pings a minute for this key |
Redirects are never used. Always use the https:// form of the URL.
Sending output
The body of a POST is stored as text, up to the first 10 KB. Longer bodies are truncated and flagged. The first 500 characters of the last failure output go into the alert.
tail -c 10000 /var/log/backup.log | curl -fsS -m 10 --data-binary @- https://ping.cronwize.com/YOUR-KEY/failRun duration
Send /start when the job begins and a success or failure ping when it ends. The duration is measured between them. A started run that does not finish within the monitor's maximum runtime marks the monitor down, so a hung job alerts even though it started on time.
Keeping the key safe
The key in the URL is the only credential a ping needs. Anyone who has it can send pings for that monitor. Keep it out of public repositories, and rotate it from the monitor's page if it leaks: the old URL stops working at once.