Safely Troubleshooting Customer Production Incidents Using MCP and AI Skills

A customer opens a support ticket:

As a Staff Solutions Architect at Qovery, this is the kind of situation I regularly investigate.

The symptom may seem simple, but the actual cause could be almost anywhere. A failed deployment, an invalid health check, an application bug, an unavailable dependency, a Kubernetes scheduling issue, or a container exceeding its memory limit can all produce similar results.

The hardest part is often not fixing the problem; it is understanding it. That means collecting enough context to determine what is actually happening.

This is where I now use Qovery's MCP server and agent skills. The agent gathers evidence, follows a consistent troubleshooting process, and prepares a recommendation I review. It does not make changes to a customer's production environment on its own.

MCP gives the agent access to real infrastructure data

You can paste a Kubernetes error into an AI assistant and ask what it means. The answer will probably be reasonable, but it will still be generic. The agent does not know which service is affected, what changed before the incident, why the container restarted, or what happened on the cluster at that moment.

The Qovery MCP server changes that by giving compatible AI agents controlled access to Qovery. Through MCP, the agent can retrieve information about:

• Organizations and projects
• Environments and services
• Deployment status
• Application and build logs
• Service configuration
• Cluster status and events

For example, I can ask:

Analyze the health of the production cluster.

Check for:
- unhealthy nodes
- scheduling failures
- recent disruption events
- pods that are repeatedly restarting

Do not make any changes.

The agent identifies the correct organization and cluster, calls the relevant Qovery tools, and summarizes what it finds. I no longer need to manually collect every identifier and copy information between the Qovery Console, logs, Kubernetes events, and my AI assistant. The agent can access the evidence directly.

Skills give the agent a troubleshooting method

Access to information is only half of the problem. An agent also needs to know how to investigate an infrastructure issue properly. This is the role of Qovery Skills. MCP tells the agent what it can access. A skill tells it how to approach a specific task.

The qovery-troubleshoot skill gives the agent a structured diagnostic process covering:

1. Cluster health
2. Kubernetes workload state
3. Container image
4. Container configuration
5. Application logs
6. Network connectivity
7. Qovery configuration
8. Resources and quotas

This prevents the agent from jumping directly to the first plausible explanation. A service returning HTTP 502 errors might have an application problem. It could also be healthy but failing its readiness probe. A pod restarting might look like a CPU issue, while Kubernetes is actually terminating it because it exceeded its memory limit.

What this looks like on a real support case

Imagine that a customer reports repeated restarts on their production backend. I can give the ticket context to my agent:

Investigate the production backend.

The customer reports repeated restarts since 09:30 UTC.

Use the Qovery troubleshooting skill and MCP tools.

Check:
- the latest deployment
- the previous stable deployment
- application logs
- container restart reasons
- Kubernetes events
- CPU and memory usage
- health-check failures

Do not modify the environment.

The agent first identifies the correct organization, environment, and service. It then checks the deployment history and finds that a new version was deployed shortly before the issue started.

Next, it retrieves the workload state and discovers:

• Six container restarts in four hours
• An out-of-memory termination
• A memory increase during a large data export
• No cluster disruption during the same period

That turns a vague complaint, “the API is unstable,” into a specific diagnosis: the container is exceeding its memory limit while processing a large export.

The agent can then prepare a reviewable recommendation:

Probable root cause

The container exceeded its 768 MiB memory limit during a large export.
Kubernetes terminated it, causing a temporary service interruption.

Evidence
- Six restarts during the last four hours
- Previous container state reports an out-of-memory termination
- Memory usage increased during the export operation
- No node or cluster disruption was detected

Immediate mitigation
Increase the memory limit to 1 GiB.

Risk
This may increase cluster capacity requirements and infrastructure cost.

Recommended follow-up
Profile the export process and avoid loading the full dataset into memory.

This is much more useful than simply asking the customer to increase memory. I can see the evidence, understand the reasoning, challenge the conclusion, and explain both the immediate mitigation and the proper application-level fix.

Using the same workflow for optimization

The same approach also works for infrastructure optimization. Qovery can generate CPU and memory recommendations from historical observability data. The report can then be analyzed by an agent using the qovery-optimize skill.

For example:

Current CPU request: 1000m
Average CPU usage: 120m
Suggested request: 250m

Reducing the CPU request from 1000m to 250m looks like an obvious saving. But an average can hide short CPU spikes. A frontend or API may stay almost idle most of the time, yet briefly require a full CPU core while processing a request. Reducing its CPU allocation too aggressively could introduce throttling and increase latency.

This is why I do not ask the agent to apply the raw recommendation directly. I ask it to add workload context:

Analyze this production service for CPU right-sizing.

Before recommending a lower CPU request:
- check average and maximum CPU usage
- look for short CPU spikes
- review CPU throttling
- consider replicas and autoscaling
- explain the reliability risk

Do not apply changes.

The final recommendation may be more conservative:

The average CPU usage is low, but the service reaches 850m during short
traffic bursts.

Reducing the request directly to 250m could increase throttling and latency.

Recommended first step:
- Reduce the request from 1000m to 600m
- Keep the existing CPU limit
- Monitor latency and throttling for seven days
- Reassess after the observation period

The goal is a better balance between cost, performance, and reliability, not the smallest possible resource value.

The agent prepares changes, but I remain in control

Giving an agent access to infrastructure does not mean allowing it to change production without supervision. My preferred workflow is read-only by default.

Before applying anything, the agent should show:

• The current configuration
• The proposed change
• The evidence supporting it
• The expected impact
• The risks
• The rollback procedure

I can then approve or reject each recommendation. Increasing memory may solve an incident but also require additional cluster capacity. Reducing CPU may lower reserved resources but increase application latency. Changing a health check may stabilize deployment, but delay the detection of a genuinely broken release. These decisions require operational and business context that the agent may not have.

The Qovery MCP integration also uses the platform's existing permissions. The agent only has access to the operations available to the authenticated user or token, and its MCP tool calls are visible in the Qovery audit logs. MCP is another interface to the platform. It does not replace RBAC, governance, or human responsibility.

The real benefit is consistency

Experienced support engineers usually have a troubleshooting process in their heads. They know which logs to inspect, how to interpret Kubernetes events, when to check the cluster, and which configuration changes could be dangerous. Skills make that process reusable. Every investigation can start from the same baseline while adapting to the customer's actual environment.

The output can also become a runbook documenting:

• What happened
• Which evidence identified the problem
• Which change resolved it
• How the fix was verified
• How to prevent the issue from returning

This is useful for me, for the rest of the support and solutions team, and eventually for customers investigating similar problems themselves.

A practical use of AI for infrastructure

The model is simple:

• The support ticket provides the initial context.
• The Qovery skill provides the investigation process.
• MCP provides controlled access to the platform.
• Logs, observability, and Kubernetes events provide the evidence.
• The agent correlates the information and prepares a recommendation.
• I validate the reasoning and control the changes.

This is how I use Qovery's agentic capabilities today. It is a troubleshooting assistant, not a chatbot guessing from an isolated Kubernetes error, and not an autonomous operator silently changing a customer's production environment. It turns “our production API keeps restarting” into a diagnosis: the container exceeded its memory limit during a large export, with the evidence, the immediate mitigation, the risk, and the long-term fix attached.

By pairing MCP for data access with Skills for diagnostic method, you turn an AI agent into an efficient investigator that transforms vague support tickets into evidence-backed diagnoses while keeping final control where it belongs: with your engineers.

Book a demo with a Qovery Solutions Architect

Resources

• What Is an MCP Server for Infrastructure?
• Qovery Skills on GitHub
• Qovery Skill for AI Agents
• Governance Starts at the Network: How We Put AI Agents in Production