Skip to main content

Suggested Remediation

Suggested Remediation gives you steps to fix an Issue. It appears in the Suggested Remediation section of the Summary tab for an Issue in the Causely portal.

How it works​

Suggested Remediation has two tiers.

  1. Diagnosis-type guidance. Every Diagnosis includes remediation guidance based on its diagnosis type. Each type has its own remediation template.
  2. Evidence-grounded remediation. When Causely has log evidence relevant to the Diagnosis, it generates a more specific remediation. Relevant evidence includes error messages, connection failures, and configuration values.

For the second tier, Causely passes the following to an LLM:

  • The Diagnosis
  • Its supporting evidence, including metrics and log lines
  • The diagnosis-type guidance

The LLM returns steps tailored to the affected entity. These often include ready-to-apply configuration, such as a corrected Kubernetes manifest.

note

The Diagnosis itself is deterministic. It is produced by Causely's causal reasoning engine. Only the remediation text is LLM-generated.

Requirements​

Diagnosis-type guidance is available for every Diagnosis. Generated remediation depends on log evidence being available to Causely.

To make log evidence available, see:

Example​

info

This is an illustrative example of how log evidence leads to a specific remediation. The output for your Issues depends on your Diagnosis, evidence, and environment.

Diagnosis: Application Error Spike on Service inventory-sync

Summary: The synchronization logic attempts to update the immutable _id field, causing database write exceptions.

Key evidence:

  • [Log | Error] Database write exception on immutable field | Count: 2,814
  • [Log | Error] Sync update failed on inventory record | Count: 537

Suggested remediation: Exclude _id from update operations

Modify the synchronization logic in the inventory-sync service so update statements never target the immutable _id field. Use _id only as a query filter, and strip it from the $set payload.

// Exclude _id from the update; use it only as the filter
update := bson.M{
    "$set": bson.M{
        "sku":      item.SKU,
        "quantity": item.Quantity,
        // _id is intentionally not included
    },
}
filter := bson.M{"_id": item.ID}
_, err := collection.UpdateOne(ctx, filter, update)

Without the log evidence, guidance for this diagnosis type would be generic ("investigate application errors"). With it, the remediation names the failing operation and the exact code change.

Review before acting​

Remediations are LLM-generated from runtime telemetry and grounded in evidence. Verify them before you act.

Check the suggested change against the supporting evidence on the Issue. Then apply it through your normal review and change process.

Use with agents​

For more specific steps, pass the remediation and its evidence to an agent that has access to your configurations, code, or runbooks. The MCP Server lets agents retrieve Diagnoses and their evidence from Causely.

  • Issues: where Diagnoses, evidence, and remediation appear.
  • Automate Remediation: executes fixes for supported resource-contention Diagnoses with one click.