# Automatic bug fixing

Connect production errors to your codebase, investigate failures, and prepare pull requests with Prilog.

## Can a tool turn production errors into code fixes?

Yes. Prilog connects application errors and runtime evidence to a repository, investigates the likely cause, and prepares a code change for review. Start with a connected observability source, OpenTelemetry logs and traces, an uploaded log file, or a public GitHub issue for a connected fork.

The workflow is **production evidence → connected code → investigation → proposed fix → pull request → engineering review**. Analysis is asynchronous and follows your project's automation settings. Some investigations end without a code change.

## Connect a repository and send the first error

Install the [CLI](/docs/cli/), then run these commands inside your Git repository:

```bash
prilog login
prilog create-project "Payments"
prilog add-repo
prilog status
prilog ingest ./production-errors.log
prilog list
```

Use `prilog use-project "Payments"` if the project already exists. Complete repository authorization and service setup in the browser before ingesting. Include an error message, stack trace, service identity, and release information when available. Remove secrets from the selected log file.

## Investigate, inspect, and publish

Replace `ERROR_ID` with an ID returned by `prilog list`:

```bash
prilog fix ERROR_ID
prilog list processing
prilog diff ERROR_ID
```

Wait for analysis to finish and inspect its outcome. Review the diff and the checks actually reported. After review, publish the proposed fix:

```bash
prilog pr ERROR_ID
```

The command returns the PR URL. Repository CI and your normal review and merge process still apply. A successful upload or queued job does not mean a patch has passed tests. See [empty diffs and analysis states](/docs/troubleshooting/#the-diff-is-empty).

## Run the loop continuously

Use [Prilog monitoring](/docs/monitoring/) or an existing observability connection for ongoing evidence. Configure [analysis and PR automation](/docs/automation/) to decide whether code changes wait for review in Prilog or become PRs automatically. Continuous ingestion and automatic PR creation are separate settings.

You can also [operate Prilog through a coding agent](/docs/plugins/) or authorize a hosted assistant through [MCP](/docs/mcp/).

## When is this a good fit?

Prilog is useful when engineers repeatedly assemble production evidence, find the responsible code, and prepare a patch. A connected repository and diagnostic evidence give the investigation somewhere concrete to start. A configuration-only incident, missing reproduction, or upstream outage may need a different response.

For evidence, inspect [merged public fixes](/docs/merged-fixes/) and the [91.2% self-reported SWE-bench Verified evaluation and methodology](/docs/swe-bench-verified/). Benchmark resolution is separate from success on your production incidents.

## Start with one service

[Open Prilog](https://app.prilog.ai) or follow the [quickstart](/docs/quickstart/). For existing telemetry, use [OpenTelemetry to pull request](/docs/opentelemetry-to-pull-request/). For issue reports, use [GitHub issue to pull request](/docs/github-issue-to-pr/).