The DevOps Case for Two Different Health Checks

November 14, 2026 3 min read Article 105

Is my machine ready, and is my project consistent, are different questions. Keeping them in different commands keeps support tickets short.

A platform team's day is mostly one question asked many ways: it does not work, what is wrong. The fastest way to answer it is to refuse to let it be one question.

Two failures that look the same

From the developer's chair, flisk up fails is one symptom. Underneath it are at least two unrelated causes. Either the machine is wrong (no container engine, a port in use, a missing runtime) or the project is wrong (a service.json that does not validate, generated files that no longer match the manifest).

Support that cannot tell these apart asks for screenshots, then asks again. Support that can tell them apart asks for one JSON blob.

One command per question

flisk doctor checks the environment: the container engine (Docker, Podman or Colima), Tilt and ports. For a project where every service declares a command, it checks only that those programs are installed. --fix repairs what it can, and --json makes the result machine readable.
flisk config verify checks the project: that generated files match .flisk/project.json and that every service.json is valid, including a circular dependsOn or a health check that names two probes.

Keeping the boundary clean is a deliberate rule in the project, not an accident. A doctor that also lints your manifests becomes a command nobody can explain in one sentence.

A diagnostic you can describe in one sentence is a diagnostic people actually run before opening a ticket.

What this saves a platform team

A thread that starts with the output of both commands is usually over in one reply. The environment is fine and the project is not, or the other way around, and the next step is obvious. Over a quarter that is a lot of small interruptions that never happen.

It also gives the platform team a place to encode what they keep repeating. A recurring cause becomes a doctor check, so the fifth person to hit it is told by the tool instead of by a human.

The scope stays local

None of this is a deployment tool, and it is not meant to be. Flisk does not emit Kubernetes manifests and does not replace Helm or Argo. The opt-in flisk export commands write render.yaml, wrangler.toml or a standalone docker-compose.yml from the same service.json files, write environment variable names but never values, and never deploy anything. flisk eject writes a plain description of the generated Tilt setup, so leaving is documented before anyone needs it.

That is the DevOps case in one line: the local loop gets better without taking ownership of production.