Sermon v1b
Log in
agent docs here
Observability for autonomous systems

Your agent already knows what's wrong.
Let it tell you.

Sermon is a lightweight observability daemon built for operators who already work with AI agents. Your agent drives; Sermon shows them what's happening.

Signups are paused. We'll email when access opens.
quick_start.sh 
# Install the daemon on each server
❯ curl -fsSL https://sermon.fyi/install.sh | bash -s -- $TOKEN

# Or start it manually after enrollment
❯ sermon agent start
[ alerts // trailheads ]

Alerts fire.
Agents act.

Tell Sentinel what to watch, in plain English. When something trips, the alert reaches you wherever you are. Reply to engage.

delivered via SMS · EMAIL · WEB
iMessage Today 14:44
Sentinel
cpu pegged on web-02 → 96% for 12m. top proc gunicorn:worker pid 18472 (84.1% cpu, spawned 14:32:11). already pulled the request log.
tap to choose
show me more
Delivered
cpu × /api/checkout traffic
100 50 0 80% 14:32 deploy cpu /api/checkout
overlay reveals the cause × correlated
tap to choose
fix it
Delivered
i'll send SIGTERM to gunicorn:worker pid 18472 and revert the api/v2.4.1 deploy. approve?
tap to choose
approve ✓
Delivered
cpu.usage_pct · web-02 · resolved
100 50 0 80% 14:46 killed
recovered to 31% baseline 31.2%
i wrote up an incident summary and post mortem ↓
RESOLVED
ALERT-0814 — web-02 CPU spike resolved Synchronous DB call in api/v2.4.1 starved worker pool. Reverted to v2.4.0; recovered to 31% baseline within 4s. sermon.fyi · postmortem
no, hold
Delivered
standing by. mute, dispatch later, or want to dig in?
tap to choose
mute 4h
Delivered
muted ALERT-0814 for 4h. re-paging if cpu > 95% or anything else trips on web-02.
schedule fix
Delivered
scheduled SIGTERM pid 18472 + revert api/v2.4.1 for 22:00 UTC. you'll get a confirm ping at 21:55 with the plan recap.
dig in
Delivered
ok. pulled the deploy diff — orders.get_recent/1 is doing a synchronous DB call inside the request handler. want me to draft a PR moving it to the async queue?
tap to choose
yes, draft
Delivered
drafted it ↓ 
- result = Orders.get_recent(user_id)
+ Task.async(fn -> Orders.get_recent(user_id) end)
DRAFT
api#413 — move orders.get_recent to async queue +18 / −7 in api/orders.ex. ready for review when you are. github.com · heimann/api
just watch
Delivered
watching. re-paging only if cpu trips again or req latency p99 > 500ms.

System architecture

Three components. A lightweight collector on each box, a central aggregator, and a protocol that any agent can call.

01 / Ingestion [daemon] 
[SERVER] ──(logs)──> +────────+
[POD-1]  ──(otel)──> | SERMON |
[SYS]    ──(proc)──> +────────+

Omnivorous daemon

Runs as a ~2MB Zig binary on every server. Reads /proc, tails journalctl, and pushes metric samples over a single authenticated endpoint. No runtime. No agent. Just the binary.

02 / Storage [duckdb + postgres] 
      ←── Vectorized
           execution
      ←── Local storage

Embedded analytics

Each daemon stores full-resolution telemetry locally in an embedded DuckDB with 7-day retention. Central Postgres aggregates across the fleet for the dashboard and long-term queries.

03 / Access [mcp / api] 
+──────+   [MCP]  +───────+
|SERMON| <======> | AGENT |
+──────+  (CLI)   +───────+
[HUMAN]

Machine-first protocol

An MCP server exposes the fleet to any agent that speaks the protocol. Your Claude Code, Cursor, or custom client queries metrics, tails logs, and dispatches alerts without touching the UI.

design_philosophy.txt

Designed for agents.
Not humans.

Traditional observability tools assume a human is staring at a dashboard, trying to correlate colored lines on a graph. Sermon assumes an AI agent is polling an API.

We deliver structured, high-density context. When something breaks, your agent receives exactly the relevant logs and correlated metrics, ready to act, not just alert.

  • Investigates root causes Agents pull the last 15 minutes of metrics, correlate with log lines, and surface likely causes.
  • Proposes remediations Sermon never executes. Your agent executes, under your trust, with the evidence it needs.
  • Runs continuous watches Long-running agents register query-as-alerts: "cpu > 80 for 5m, fire with context."
agent_session_id: 9x4-aql live

agent: Evaluating cluster state…

agent: Anomalous latency detected on aniara-1. Pulling correlated logs. 

  mcp.tool: query_metrics
payload: { "server": "aniara-1", "since": "-15m", "fields": "cpu,mem" }

system: Returned 600 samples. cpu_percent crossed 80% at 13:57:06; sustained 5m.

agent: Correlating with nginx logs... found worker crash at 14:02:03. Proposing fix.

action proposed
Restart nginx Dismiss
[ join_waitlist ]

Give your agents eyes.

Stop forcing LLMs to scrape dashboards. Give them the structured telemetry they need to act autonomously.

Signups are paused. We'll email when access opens.
View on GitHub
© 2026 Sermon · All rights reserved