Automatic bug fixing

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, then run these commands inside your Git repository:

$
$
$
$
$
$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:

$
$
$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:

$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.

Run the loop continuously

Use Prilog monitoring or an existing observability connection for ongoing evidence. Configure analysis and PR 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 or authorize a hosted assistant through 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 and the 91.2% self-reported SWE-bench Verified evaluation and methodology. Benchmark resolution is separate from success on your production incidents.

Start with one service

Open Prilog or follow the quickstart. For existing telemetry, use OpenTelemetry to pull request. For issue reports, use GitHub issue to pull request.