There is a jaque running in public at demo.jaque.sh. It monitors real targets, decides their states on its own, and serves the same dashboard the binary serves anywhere else. Nothing on it is scripted.

No account and no credentials. Open it and you are looking at the current state of the estate it watches.

What it monitors

Open DNS resolvers, published status APIs, and the demo's own stack. Nine hosts, twenty-eight checks. Every target is an endpoint its owner publishes for public consumption, which is the only kind of thing a public demo has any business probing.

The config it runs is published by the instance itself, at demo.jaque.sh/demo.cue -- the same file, not a copy of it. That is the point of it. A monitoring demo whose config you cannot read is a screenshot with extra steps, and the states you see on the page mean nothing unless you can check what produced them.

One detail worth reading in that file: every external host declares demo-host as its parent. The box runs the checks, so if it loses its uplink all nine targets fail at once. The parent edge turns that into one alert about the box instead of nine about the internet, which is the dependency model doing its job on the smallest estate that can show it.

It is read-only, and that is enforced

You cannot acknowledge, schedule a downtime, or submit a passive result. The controls are not merely hidden: the instance runs with -read-only, so every mutating surface is unmounted and the command API answers 404.

It also runs with -config-profile demo, which narrows the config schema itself. No command, legacy or WASM checks, no sinks that write files or run programs, at most 25 hosts with 10 services each, and no check interval under 30 seconds. A config that asks for any of it fails to load, so the restriction holds against whoever edits the config, not just against whoever visits the page.

Both flags are documented in CLI flags, and they are how you would run your own public instance.

It resets

The instance is wiped and restarted nightly. The event log does not survive, so the history you see is at most a day of it, and the states on screen are the ones the checks produced since the last reset.

That is deliberate. A demo that accumulates is a demo that eventually shows a year of somebody else's noise, and the thing worth showing is what the engine decides now.

Running it yourself

contrib/demo/ is the whole stack, and it is the same one the demo host runs:

bash contrib/demo/reset.sh

That is also how a change to the demo gets validated before it is deployed rather than after.