Introduction
Fixter is a monitoring platform for small engineering teams. It stores your logs, traces, and metrics, answers questions about them in plain language, and when something breaks it investigates and reports what caused it.
It is built around AI coding agents. Setup, querying, alerting, and investigations all work from your editor over MCP. A web app and a SQL dialect cover the same ground for when you want them, but neither is required.
How it works
Section titled “How it works”1. Instrument
Section titled “1. Instrument”Fixter ingests OpenTelemetry over OTLP and there is no proprietary agent. You send three signals from your own services: traces of each request through your code, your application logs, and metrics. Calls your application makes to OpenAI, Anthropic, or LangChain are instrumented too. Auto-instrumentation covers the usual sources without you writing spans by hand: your web framework, your database driver, and outbound HTTP calls. On Kubernetes the Fixter collector also picks up pod logs and cluster metrics without touching your application at all.
You do not wire this by hand. The Claude Code plugin detects your language and framework, adds the matching packages and configuration, and provisions your API key through a one-time link, so the key never appears in chat or in your repository. On a stack without Claude Code you set four environment variables yourself, which is the OTLP path. Either way the Onboarding walks it.
2. Debug
Section titled “2. Debug”Data is queryable seconds after it arrives. When something looks wrong you ask your agent in plain language (“why did checkout error rate spike after the 14:10 deploy?”), and it searches the logs, follows the traces, and answers. The app provides search, charts, and live tail over the same data, and QuerySQL is there where a question needs to be exact. See Debugging.
3. Alerts
Section titled “3. Alerts”Rules come from two places.
- You define them. Describe what matters in plain language, such as payment failures or latency on checkout, and the plugin turns that into rules.
- Fixter finds the rest. Its own detectors run over your data continuously and alert you to error bursts, anomalies, and budget burn without you configuring anything.
Both kinds are ordinary alert rules you can review, edit, or disable.
4. Investigations
Section titled “4. Investigations”When an alert fires, an AI agent picks it up and does the first pass for you. It queries your telemetry, reads the logs and traces around the failure, works out the root cause and the blast radius, and replies in the Slack thread the alert arrived in. Ask it follow-up questions there and it answers with everything it already examined still in context.
5. Fix
Section titled “5. Fix”An AI agent does the work on either route. Hand the investigation to your own AI coding agent, which picks it up with the full transcript and works in your local checkout. Or install the GitHub App and an AI agent writes the change and opens a pull request on the affected repository, in beta today and reviewed by someone at Fixter before it reaches you. Nothing is ever merged for you. Both routes are on the investigations page.
Start here
Section titled “Start here”- Onboarding: the guided path from nothing to alerts investigated
- Telemetry: what Fixter collects and why each signal matters
- Send data with OpenTelemetry: OTLP configuration per language
- MCP tools: everything a connected agent can do