Signal types

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

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

The POST body is stored in history: up to 10 KB on Free and 100 KB on paid plans. Requests over 100 KB are rejected with HTTP 413. Failure alerts include only the tail of the stored log, limited by the channel format. Send the last lines of output without secrets.

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

Concurrent runs

Generate a new UUID for each concurrent run and send the same rid with /start, /log and the final ping. Each run has its own duration and timer. One success does not resolve an alert while another run exceeds its maximum duration. An invalid or empty rid returns HTTP 400.

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

Repeating /start with the same rid does not extend the timer, and repeating a final ping does not count as another failure. Use a new rid for the next run. Pings without rid use a separate single-run slot and cannot finish a named run. Run records follow your plan’s history retention; unfinished runs with a longer permitted duration are kept until that duration expires, plus one hour.