Slow Execution Diagnosis Skill🔗

The Slow Execution Diagnosis Skill guides an AI assistant through performance investigations in live applications using Lightrun MCP. It helps the assistant diagnose slow endpoints, latency or SLO regressions, timeouts, deadline-exceeded errors, and hangs by collecting duration-based runtime evidence instead of relying only on logs, traces, or static code analysis.

The skill is available in the lightrun-ai repository as lightrun-slow-execution-diagnosis.

Before using this skill, install the shared Lightrun AI Skills package and complete the requirements in Lightrun AI Skills.

When to use this skill🔗

Use the Slow Execution Diagnosis Skill when you want an AI assistant to investigate a live performance incident with evidence from Lightrun MCP.

This skill is useful when:

• An endpoint, method, or code section is slow, intermittently slow, or slow only under load.
• Requests time out, exceed a deadline, or miss an SLO or latency budget.
• A request or thread appears to hang and may never complete.
• You need to compare slow executions with normal ones using a duration threshold.
• The issue mixes slowness with incorrect results, and you want the performance path investigated first.

For functional bugs that are not performance incidents, use the Live Runtime Debugging Skill. For a one-off timing or value question that is not an incident investigation, use the Ask Prod Skill.

How to use this skill🔗

Start a new AI assistant chat and ask the assistant to use the Slow Execution Diagnosis Skill for the performance issue you want to investigate.

Use a prompt like this:

Use the Lightrun Slow Execution Diagnosis Skill to investigate this issue.

Issue:
Checkout requests to POST /api/v1/checkout are intermittently exceeding 500 ms, and some fail with deadline-exceeded errors.

Target service:
checkout-service in production.

What I know:
The slowness appears around CheckoutService.processOrder. I do not know which executions are slow or why.

The assistant should begin by confirming the performance question, locating the relevant code, and running the Lightrun MCP preflight check. It should then select a runtime target and choose an evidence path before creating any runtime actions.

What the skill does🔗

The skill gives the assistant a structured workflow for moving from a performance symptom to a diagnosis:

• It starts with source discovery and a concrete runtime target before capturing evidence.
• It selects the smallest code section that can test the performance hypothesis.
• It prefers slow-execution snapshots when a duration boundary, such as a timeout, deadline, or SLO, separates problematic executions from normal ones.
• It derives that threshold from existing evidence instead of inventing one.
• It uses a focused snapshot and call stack when a hang may never reach an end marker, or when duration discrimination is not needed.
• It correlates captured runtime state with code, logs, metrics, and traces.
• It ends with a single outcome: diagnosed, inconclusive, blocked, or waiting for reproduction.

This approach helps the assistant capture the executions that matter, instead of sampling every request or guessing from static code.

Runtime support🔗

The evidence the assistant can collect depends on the target runtime and Lightrun version:

On non-JVM runtimes, the assistant can still investigate with regular snapshots and call stacks. It cannot use duration measurements or threshold-triggered snapshots for those targets.

For details on the underlying MCP tools, see Capture snapshots for slow executions.

Expected investigation flow🔗

During a successful investigation, the assistant should:

1. Confirm the symptom, impact, expected latency or timeout, and investigation question.
2. Run get_runtime_sources_agent_pools to list the available agent pools, then get_runtime_sources_agents to list the agents and tags in the selected pool.
3. Select the most relevant runtime target or ask you to choose if several targets match.
4. Inspect the relevant code and choose the smallest section that can explain the slowness, timeout, or hang.
5. Choose an evidence path:
   • Slow-execution snapshots when a timeout, deadline, SLO, or measured baseline can define a duration threshold.
   • A focused regular snapshot when the suspected hang may not reach an end marker, or when duration discrimination is not required.
6. Create the runtime action, keep track of the action ID, and ask you to reproduce the issue while the action is active.
7. For slow-execution snapshots, poll duration samples and snapshot values independently, then correlate captured state with the slow executions.
8. Produce a final handoff with the diagnosis or remaining gap, the evidence collected, the runtime source and code range, the threshold used, and any remaining actions.

Troubleshooting🔗

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.

Runtime source discovery returns no sources🔗

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.

Slow-execution snapshots are not available🔗

Confirm that the target is a Java, Kotlin, or Scala service running Lightrun 1.89 or later with a compatible JVM agent. If the slow-execution snapshot parameters are not exposed, the assistant should say so and continue with a supported evidence path, such as a focused regular snapshot.

Runtime actions return no hits🔗

Confirm that the selected runtime source matches the code path you are investigating. If the slow path is infrequent, ask the assistant to keep the action active and reproduce the issue again. If a hang never reaches the selected end line, ask the assistant to retarget with a focused snapshot on the active path.

The duration threshold is unclear🔗

Provide the timeout, deadline, SLO, or a latency value from logs, metrics, or traces. The assistant should derive the snapshot threshold from that evidence. If no boundary exists, it can collect baseline timing first on supported JVM runtimes, then set the threshold from the baseline.

The runtime target is unclear🔗

Ask the assistant to compare the available runtime sources and explain which one best matches the service, environment, or expected trigger path. If confidence remains low, choose the source manually.

Related topics🔗

• Lightrun AI Skills
• Live Runtime Debugging Skill
• Ask Prod Skill
• MCP quickstart guide
• Supported Lightrun MCP tools