Signal types

Start, success, failure and free-form logs — what to send and when.

The ping address takes an optional suffix. The suffix defines what the signal means.

bash

https://ping.tickwatch.dev/YOUR-KEY          # успех
https://ping.tickwatch.dev/YOUR-KEY/start    # задача началась
https://ping.tickwatch.dev/YOUR-KEY/fail     # задача упала
https://ping.tickwatch.dev/YOUR-KEY/0        # успех, код возврата 0
https://ping.tickwatch.dev/YOUR-KEY/17       # падение, код возврата 17
https://ping.tickwatch.dev/YOUR-KEY/log      # просто лог, состояние не меняется

Why the start signal

Without it we only know the job did not report, not why: it never started, or it started and has been hanging for three hours. The start signal separates the two and enables the maximum-duration check.

Request body

Whatever you send as the POST body is stored as the run log and included in the failure alert. It is truncated to the plan limit, so sending a multi-megabyte dump makes little sense — the last lines are usually enough.

bash

/path/to/job.sh 2>&1 | tail -c 10000 | curl -fsS --data-binary @- https://ping.tickwatch.dev/YOUR-KEY

Concurrent runs

If one job can run in several instances, add an rid parameter with a unique run id — then starts and finishes pair up correctly instead of interleaving.

bash

RID=$(uuidgen)
curl -fsS "https://ping.tickwatch.dev/YOUR-KEY/start?rid=$RID"
/path/to/job.sh
curl -fsS "https://ping.tickwatch.dev/YOUR-KEY?rid=$RID"