An event router that lives inside your application.

You declare the classes of occurrence you care about. When one happens, Kepler enriches it with in-VM context that is unavailable from outside the BEAM, and delivers it to an external consumer. Deterministic, passive, always-on: it observes and reports, and it never remediates.

defmodule MyApp.Watches do
  use Kepler

  watch :process_crash do
    source crash_report: :any
    enrich [:stacktrace, :process_state, :last_message, :request_context]
    severity :error
    fire immediately, cooldown: :timer.minutes(1)
  end
end

See the getting started guide to wire that up, crash attribution for the source above, and writing watches for the language in full.

The two things this sells

For any single signal, :telemetry.attach plus an HTTP post is about twenty lines. Kepler earns its place on two counts, and every feature is judged against them.

Enrichment at fire time. A crash event carrying the dying process's state, its last message, its stacktrace, and the request that caused it. Nothing outside the VM can assemble that.

Safe egress from a hot BEAM. Fifteen hand-rolled webhook-firing telemetry handlers across a production app will eventually take prod down — a slow HTTP call inline on a hot path, or an event storm hammering your own SIEM during an incident. Kepler is the one correct, bounded, non-blocking way for events to leave a live VM.

Not a metrics backend, and not Alertmanager

No time series, no query language, no dashboards; telemetry_metrics and Prometheus exist and are better at it. The distinction that matters:

If a signal can be expressed as a threshold on a bounded-cardinality time series, it is not Kepler's job.

The shape of the thing

Telemetry handlers run inline in the process that emitted the event, so a slow handler directly slows your checkout path. Kepler's handler therefore does one thing: an atomic increment of a lock-free counter. No allocation, no message send, no ETS write.

A single poller then wakes on a tick, reads the counters, computes deltas, and evaluates every declared condition in one pass. Event volume and evaluation volume are decoupled: 100k events per second costs 100k atomic increments plus one evaluation pass per tick.

Signal tiers, by cost

Every source belongs to a tier, and Kepler.Watch records which:

Discrete tier 0 sources bypass the counter path and fire directly, but still go through the same bounded, non-blocking egress as everything else.

Three options add per-event work to a tier 1 watch, and all are opt-in for that reason: filter runs a comparison on the emitting process, and recent and enrich each write to a ring buffer. On a report source enrich is free — the report already carries the fields.

There is no tracing tier. It is the highest-risk surface and the least necessary; if you need it, :recon_trace already has the rate limiter and hard message cap that make it safe.

Deliberate limits

• Single node. Each node observes and fires independently. There is no cross-node deduplication, because distributed coordination in the hot path is how lightweight things stop being lightweight. Events are tagged with the node that produced them.
• Best-effort egress only. Delivery is in-process. A delivery lost to a crash is not retried after restart, and a wedged endpoint gets counted drops rather than an unbounded buffer. guarantee: :at_least_once is declarable now, warns at boot, and behaves as best-effort until the durable buffer lands.
• No storage. Kepler holds counters and a small ring of recent events. It is not a metrics backend; telemetry_metrics and Prometheus already are one.

The public contract

Each watch name is the stable event id consumers route on. Renaming a watch is a breaking change for whoever is on the other end of the webhook.