Skip to content

Error Remediation Automation Skill🔗

The Error Remediation Automation Skill helps an AI agent process captured application errors from tools such as Sentry, Datadog, New Relic, Dynatrace, Splunk, or any other error monitoring system.

The skill is available in the lightrun-ai repository as lightrun-error-remediation-automation.

Use this skill when you want an automation to collect errors, send each error to an AI agent, and use Lightrun MCP to add live runtime context to the investigation.

Watch the demo🔗

The following demo shows autonomous error remediation in Cursor with Lightrun MCP.

Set up the automation🔗

  1. Install the skill

    Install the shared Lightrun AI Skills package in your AI client. For setup instructions, see Lightrun AI Skills.

    If the skill is not installed, ask the AI agent to install the Lightrun AI Skills package from the lightrun-ai repository and confirm that /lightrun-error-remediation-automation is available.

  2. Connect the tools

    Connect the automation runner to:

    • Your error source, such as Sentry, Datadog, New Relic, Dynatrace, Splunk, or another monitoring system.
    • Lightrun MCP. For setup instructions, see the MCP quickstart guide.
    • The source repository for the affected service.
    • Optional: your ticketing, issue, pull request, or chat tool.
  3. Add a trigger

    Choose when the automation should run. For example, run it every hour, when a high-severity error appears, when an incident is opened, or when a user starts it manually.

  4. Add the AI instruction

    Tell the AI agent which errors to collect and where to store or publish the investigation result. The following prompt is an example that you can adapt to your error source, service, repository, and output destination.

    Get the list of errors from Sentry in the Lightrun production backend for the last hour.
    Process each error one by one with /lightrun-error-remediation-automation.
    
    Additional source code can be found in the lightrun-platform/lightrun repository.
    Use Lightrun MCP to inspect the live runtime context when needed.
    
    For each error, return:
    - The error summary.
    - The Lightrun runtime source used for investigation.
    - The root cause analysis.
    - The recommended next action.
    - Whether the result should remain in the automation run history or enrich a ticket, issue, pull request, or chat thread.
    
  5. Review the output

    The automation can store the full investigation and RCA in its run history. If you connect a ticketing, issue, pull request, or chat MCP server, the AI agent can also enrich the relevant record with the findings.

How it works🔗

Error tool
Sentry, Datadog, New Relic, Dynatrace, Splunk
Automation runner
Cursor, n8n, Claude, webhook, or schedule
AI agent
/lightrun-error-remediation-automation
Lightrun MCP
Live runtime context
Results
Run history, ticket, PR, chat, or custom destination

Troubleshooting🔗

The assistant cannot access the error source🔗

Confirm that the Sentry, Datadog, New Relic, Dynatrace, Splunk, or custom error-source MCP server is connected and authenticated. If the error tool does not provide MCP access, configure the automation to pass the captured error details directly to the AI agent.

The assistant cannot find Lightrun MCP tools🔗

Confirm that Lightrun MCP is installed, enabled, and authenticated in your AI client. Then ask the assistant to list the available Lightrun MCP tools.

For setup instructions, see the MCP quickstart guide.

The assistant cannot find a matching runtime source🔗

Confirm that the target application is running with the Lightrun agent connected and that your Lightrun user has access to the relevant agent pool, tag, or custom source.

If several runtime sources look similar, include the service name, environment, tag, agent pool, or custom source in the automation instruction.

The automation processes too many errors🔗

Add filters before invoking the skill. For example, process only new errors, high-severity errors, errors from a specific service, or errors that crossed a defined frequency threshold.


Last update: June 7, 2026