Dokkit Claim a name soon

DokkitMove over

Move over

Paste what you watch with today and get dokkit.toml files back, each one read by the real checker, with what could not come over and why.

Bring it over

Paste or drop a Healthchecks export, an Uptime Kuma backup, or a list of ping URLs. It is converted here, in the page, and each file is read by the program's own checker. Nothing is uploaded.

Start from
Paste here

Loading the checker

What becomes what

From Healthchecks checks list

The export is the checks list of the Healthchecks API (GET /api/v3/checks/), or the same list on its own. One file per check, its slug (else its name) as the service and job id.

  • A cron check becomes a [[job]] with the same schedule, grace from its grace, and max_runtime the same, as Healthchecks calls a started run down once its grace passes.
  • A schedule in a time zone other than UTC is kept as written, with a comment in the file: Dokkit reads every schedule as UTC, so it must be shifted by hand.
  • A simple check, a period since the last ping, becomes a job with one slot each period (*/5 * * * * for five minutes) and a grace of the period less a minute, so a ping any time in the period counts. Periods no cron line repeats evenly keep no schedule.
  • A systemd OnCalendar schedule. Tags, descriptions, keyword filters and integrations.
From Uptime Kuma monitorList

The backup file from Settings, Backup (version 1.x), read from its monitorList. One file per monitor, its name as the service id.

  • http becomes an http check: interval as every, timeout, accepted_statuscodes as status, retries plus one as fail_after.
  • port becomes a tcp check with its host and port.
  • push becomes a job, the period mapped as for a simple Healthchecks check.
  • keyword, json-query, ping, dns, docker, gRPC, databases and the rest: Dokkit has no check like them. Upside-down monitors, signed-in or non-GET requests. Headers, proxies and the TLS switch are not carried.
From a list of ping URLs one per line

One [[job]] per line, all in one service, moved-jobs, so one app key pings them all. The id is the last part of the address that is a name; an address that holds only a key is named after its host.

  • A schedule: a URL does not say when the job runs. Add a schedule for Dokkit to call it late.

Then call Dokkit

Each job keeps calling the old address and calls Dokkit's as well, until Dokkit has been right about it for long enough to trust. Paging stays with the old tool until then.

https://your.domain.com/api/v1/in/<app key>/job/<job id>/start
https://your.domain.com/api/v1/in/<app key>/job/<job id>/ok
https://your.domain.com/api/v1/in/<app key>/job/<job id>/fail

GET or POST. A POST body is kept as the last lines of the job's output, up to 16 KB, and ?run= ties a start to its finish. The key is the service's app key (dka_).

Send a file of jobs with that key. A file with http or tcp checks goes on a machine with dokkit, which runs them, in a folder it reads or sent with the machine's key.

DOKKIT_KEY=dka_... dokkit apply nightly-backup.dokkit.toml

On a machine with dokkit, wrap the job instead: it reports the start, the exit code, the time taken and the last lines of output.

dokkit run --job nightly-backup -- ./backup.sh

Next:

Check a fileEdit one and see what Dokkit will watchThe ping URLsIn the API, with every answerInstall itThe server, then the program on each machine