Kepler's supervision tree, started for you when the :kepler application boots.

Adding :kepler to your dependencies is enough — the tree starts inside your release when your application boots, and there is nothing to add to your own supervisor.

Shape

Kepler.Supervisor            :rest_for_one
├── Kepler.TaskSupervisor    delivery tasks
├── Kepler.Emitter           bounded queue, sinks
├── Kepler.Registry          counters, rings, telemetry handlers
├── Kepler.SystemMonitor     tier 0, or :ignore if it yielded
└── Kepler.Poller            the tick

The strategy is :rest_for_one because the order is a dependency order. Kepler.Registry owns the ETS tables and counter refs the poller reads, so a registry restart has to take the poller with it; the poller reinstalls from a fresh registry on the way back up. Restarting the poller alone never reinstalls anything, which is what you want when only the poller crashed.

Starting it yourself

If you would rather control the lifecycle — a test that needs specific watches, or an application that decides its config at runtime — set config :kepler, enabled: false and start this supervisor with explicit options, which override the application environment:

Kepler.Supervisor.start_link(
  watches: MyApp.Watches,
  sinks: [{Kepler.Sink.Callback, handler: &MyApp.handle/1}]
)

Its children are named, so only one Kepler runs per node.