Sermon v1b
agent docs Log in
api-1 · storefront · live tailing
4 services · no rules configured

Your logs are
talking.
You're not listening.

SermonWarning

Persistent 403s on /v2/orders

312 Forbidden on /v2/orders in 4 minutes, all from one API key (acme-prod). This route normally 200s. Their token expired at 14:05; the client keeps retrying.

14:09 UTCjudged, no rules

Point it at your logs. Sermon judges, alerts, replies.

Onboarding the first operators by hand
STEP 01 / 05
live tail
[ alerts // trailheads ]

Alerts fire.
Sermon acts.

No watchlist, no thresholds: Sermon decides what deserves your attention. The alert reaches you wherever you are. Reply to engage.

delivered via SMS · EMAIL · WEB
iMessage Today 14:44
Sermon
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

Logs in, judgment out. Ship telemetry from anywhere; Sermon reads it continuously and interrupts you only when something is real.

01 / Ingestion [otlp · daemon] 
[APP]  ──(otlp)──> +────────+
[SVC]  ──(logs)──> | SERMON |
[HOST] ──(proc)──> +────────+

Logs from anywhere

OTLP logs, metrics, and traces over one authenticated HTTP endpoint. For boxes you own, an optional ~2MB Zig binary reads /proc and journald; full-resolution history stays on the box in an embedded DuckDB with 7-day retention, and the daemon pushes samples and the log lines that matter.

02 / Judgment [model · no rules] 
baseline ─┐
          ├──> judge ──> ok · silence
window ───┘         └──> WARNING · page

A judge, not a rulebook

On every cycle a model reads each server's recent activity against its own baseline and decides: noise or signal. Info stays silent. Warning and critical become alerts with the diagnosis already written. No thresholds, no rule library, nothing to configure.

03 / Response [email · sms · imessage] 
ALERT ──> you ──(approve)──> executed
             └──(hold)─────> standby

The approval gate

Alerts reach you where you already are. Your reply is the next instruction: show me more, fix it, hold. Proposed fixes execute only after you approve, and every incident ends in a postmortem written by Sermon.

design_philosophy.txt

Sermon does the watching.
You keep the wheel.

Traditional observability tools assume a human is staring at a dashboard, trying to correlate colored lines on a graph. Sermon assumes nobody is watching, and watches anyway.

When something breaks, the alert arrives with the diagnosis attached and a fix waiting. Nothing executes until you approve. That gate is the product.

  • Investigates root causes Alerts arrive with the evidence: the metrics that moved, the log lines that matter, the likely cause in plain English.
  • Proposes gated fixes Every action ships as a proposal. Approve, hold, or dismiss; nothing runs without you.
  • Works with your agent An MCP server exposes the same corpus to Claude Code, Cursor, or any MCP client. Your agent sees exactly what Sermon saw.
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
[ get_set_up ]

Point it at your logs.

Sermon judges, alerts, and replies. You approve. Works over OTLP today; the daemon adds host metrics for boxes you own.

Onboarding the first operators by hand. We'll email when it's your turn.
View on GitHub
© 2026 Sermon · All rights reserved