# Introduction

> What Fixter is, what it does with your telemetry, and the five steps that make up the platform.

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

### 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](/setup/opentelemetry/). Either way the
[Onboarding](/getting-started/onboarding/) walks it.

### 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](/reference/querysql/) is there
where a question needs to be exact. See [Debugging](/using-fixter/debugging/).

### 3. Alerts

Rules come from two places.

1. **You define them.** Describe what matters in plain language, such as payment
   failures or latency on checkout, and the plugin turns that into rules.
2. **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](/using-fixter/alerting/) you can review, edit, or
disable.

### 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

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](/using-fixter/investigations/).

## Start here

- [Onboarding](/getting-started/onboarding/): the guided path from nothing to alerts investigated
- [Telemetry](/using-fixter/telemetry/): what Fixter collects and why each signal matters
- [Send data with OpenTelemetry](/setup/opentelemetry/): OTLP configuration per language
- [MCP tools](/reference/mcp-tools/): everything a connected agent can do