Convex component that analyzes deployment logs to surface wasted reads, real errors, abuse patterns, and Database I/O pace using rules and one LLM call per wind
npm install convex-tripwireTripwire is a Convex component that ingests your deployment's log stream, rolls it up into per-function window totals, and runs a combination of deterministic rules and a single model call per window to surface findings: excessive document reads, validator contract failures, error patterns, abuse signals, and Database I/O budget pace. Findings are written to a Convex table your app can subscribe to reactively. A CLI forwarder pipes logs from outside the deployment since components cannot subscribe to their own log stream.
Tripwire folds log events into per-function totals each minute, then at the end of each window compares bytes read against bytes returned. Functions that read significantly more than they return are flagged as waste candidates, and the model assigns a probability. The finding includes a suggested fix from a catalog of actions like adding a withIndex() query to replace a full table scan.
Tripwire ingests forwarded logs via a POST endpoint at your deployment site, rolls them up per function per window, and runs rule-based checks for runtime errors and return value validator mismatches. Findings are written to a Convex table your app can subscribe to with a query, and Tripwire can POST to a Slack or Discord webhook when a new finding opens.
After configuring Tripwire with ioBudgetBytes set to your plan limit, the component computes read throughput across all forwarded windows and projects it to a 30-day rate. When the projected rate exceeds the budget a quota finding is raised, giving you a specific GB-per-month estimate before you breach the limit.
Tripwire's forwarder aggregates raw log events into per-function per-minute totals before sending them to the component, so the component never stores individual log lines. At window close, one request to the Jev model from TypeSafe AI carries every question for every active function in that window, returning probabilities and fix selections rather than free text. Bring your own JEV_API_KEY; without it, rules and arithmetic still run.
No. The tripwire forward process folds raw log events into one row per function per minute before they are sent to the component. The component only accumulates those totals. Raw log lines are never written to the database, keeping the component's own read footprint small. Totals older than one week are deleted, and per-function moving averages retain what they learned.
Yes. Without a JEV_API_KEY environment variable, Tripwire still runs all rule-based checks and arithmetic: broken return validators, runtime error counts, and Database I/O pace against your configured budget. The model is only consulted to classify ambiguous cases like waste versus intentional reads and noise versus real defects. You can try the CLI path first with npx convex-tripwire check logs.jsonl to see what rules alone produce.
Tripwire explicitly ignores its own function names when processing window rollups, so the component never raises findings about its own ingest, judge, or query functions. This prevents feedback loops where monitoring overhead gets flagged as a problem.
Calling tripwire.resolve(ctx, id, 'noise') mutes that finding permanently for that function. If you close it as 'fixed' instead, a new finding can reopen if the same pattern returns in a later window. Both verdicts are stored as labels and feed the calibration report, which shows per probability band how many judged findings turned out to be real, letting you assess whether the model's scores are meaningful on your workload.
When tripwire forward starts, it queries the component for the furthest log position already ingested and skips any events before that point. This makes restarts safe. You can also run it with --once to catch up and exit, which suits scheduled job environments, or with --file logs.jsonl to backfill from a saved log export.