Uptime monitoring, from your terminal

Up is not the same as healthy.

Genki checks whether a service responds, then whether it is behaving correctly. Self-host one ordinary Worker and D1 database, then operate everything with a CLI.

$curl -fsSL https://genki.sh/install.sh | sh

Read the docs

Self-hosted by default

From an empty directory to a meaningful check.

01
Initialize
Create a standalone server project with the runtime, migration, and tests included.
```
$genki server init monitoring
cd monitoring
bun install
```
02
Deploy
Provision one D1 database, set the operator token, and deploy an ordinary Worker.
```
$genki server setup
npx wrangler secret put API_TOKEN
genki server deploy
```

Connect

Save the server as a named context. The same CLI also works with compatible hosted backends.

$printf '%s' "$GENKI_TOKEN" | genki context add personal \
  --url https://genki-self-host.<you>.workers.dev \
  --token-stdin
genki context use personal

Monitor

Define health once, attach an endpoint, and run the exact check immediately.

$genki monitor create public-api \
  --name "Public API" \
  --kind http \
  --config '{"expectedStatus":200,"jsonAssertions":[{"pointer":"/status","equals":"up"}]}'

genki environment create public-api/production \
  --name Production \
  --role production \
  --config '{"url":"https://api.example.com/health"}'

genki environment check public-api/production
genki status

The useful distinction

Availability tells you if it answered. Health tells you if the answer is right.

Down: The service could not be reached.
Degraded: The service responded but failed a health assertion.
Operational: The service responded and passed every assertion.

Up is not the same as healthy.

From an empty directory to a meaningful check.

Initialize

Deploy

Connect

Monitor

Availability tells you if it answered. Health tells you if the answer is right.