Skip to main content
The Kestrel Cloud AI Copilot lets you ask questions about your Kubernetes clusters, cloud accounts, code repositories, metrics, and costs in plain English. Query resources, investigate incidents, analyze spend, and generate configuration changes — all through a conversational interface in the Kestrel dashboard or the /kestrel Slack command.

​
What the Copilot Can Do

Kubernetes Investigation

Query pod logs, events, resource specs, deployments, metrics, and network policies across your clusters.

Cloud Investigation

Inspect AWS and OCI resources, security configurations, CloudTrail events, CloudWatch metrics, and VPC Flow Logs.

Code Investigation

Search files, read source code, trace change history, and look up IaC definitions across GitHub and GitLab repositories.

Cost Analysis

Query AWS spend breakdowns, identify cost trends, detect anomalies, and forecast future costs.

Configuration Changes

Generate Kubernetes YAML, Terraform, Helm, and CloudFormation changes with an approval workflow before applying.

​
Getting Started

1

Open the copilot

Navigate to Cloud AI Copilot → Chat in the Kestrel dashboard sidebar. Alternatively, use the /kestrel slash command in any Slack channel if the Slack integration is connected.
2

Target your infrastructure

Use @cluster-name to target a specific Kubernetes cluster and @cloud:connection-name to target a specific AWS or OCI account. You can mention multiple targets in a single query.
3

Ask a question

Type your question in plain English and press Enter. The copilot maintains conversation context, so follow-up questions work naturally.
Examples: 
@prod-eks-cluster Why are pods in the payments namespace restarting?

@cloud:prod-aws Show me all S3 buckets that are publicly accessible

@prod-eks-cluster @cloud:prod-aws What changed in the last 2 hours that could explain the spike in 5xx errors?

​
Targeting Syntax

The copilot needs to know which infrastructure to query. Use the @ prefix to target specific clusters and cloud accounts.
SyntaxTargetExample
@cluster-nameKubernetes cluster@prod-eks-cluster show me crashing pods
@cloud:connection-nameAWS or OCI account@cloud:prod-aws list EC2 instances in us-east-1
Multiple targetsCross-resource queries@prod-eks @staging-eks compare memory limits for auth-service
You can find your cluster and connection names on the Clusters and Cloud Connections pages in the Kestrel dashboard.

​
Integration Prerequisites

The copilot answers are only as good as the integrations connected. Each integration unlocks additional capabilities:
IntegrationCopilot Capabilities
KubernetesPod logs, events, resource specs, deployments, namespaces, network policies
AWSEC2, S3, RDS, IAM, VPC, Lambda, CloudTrail, CloudWatch, Cost Explorer, VPC Flow Logs
OCICompute, Object Storage, VCN, IAM, Audit logs, VCN Flow Logs
DatadogMetrics, monitors, dashboards, APM traces
OpenTelemetryTraces, metrics, and spans
GitHubCode search, file reading, commit history, PRs
GitLabCode search, file reading, commit history, MRs
Knowledge SourcesConfluence, Jira, Slack history, Glean, Linear context
The more integrations you connect, the more context the copilot has. Connecting observability, code, and knowledge sources alongside your clusters and cloud accounts produces significantly richer answers.

​
Using via Slack

With the Slack integration connected, use the /kestrel slash command anywhere in your workspace: 
/kestrel @prod-eks-cluster what pods are crashing in the checkout namespace?

/kestrel @cloud:prod-aws who modified the IAM policy for the deploy role yesterday?
Kestrel responds in-thread so conversations stay organized. Other team members can see the answers and ask follow-ups in the same thread. The copilot also works inside Kestrel incident notification threads, where it automatically has the incident context.

​
Example Conversation

You:
@prod-eks-cluster Why are pods in the checkout namespace restarting? Cross-reference with Datadog metrics.
Kestrel:
Two pods in the checkout namespace are in CrashLoopBackOff: checkout-api-7f8b9c-x4k2m and checkout-worker-6d4a8b-j9n3p. Both started crashing 23 minutes ago after deployment checkout-api was updated to image tag v2.14.0. Datadog shows P99 latency spiked from 120ms to 4.2s at 14:32 UTC, coinciding with the deployment. The container logs show FATAL: too many connections for role "checkout_svc" — the connection pool was exhausted.
You:
What PR caused that deployment change?
Kestrel:
The deployment was updated via ArgoCD sync at 14:32 UTC. The change originated from PR #847 in acme/checkout-service, authored by @jane.doe and approved by @john.smith. The PR modified the database connection pool settings, reducing maxConnections from 50 to 10. This matches the too many connections error in the logs.
You:
Roll back the deployment to the previous image tag.
Kestrel:
Here’s the proposed change to roll back checkout-api to image tag v2.13.2: (displays diff with Apply, Create PR, and Copy options)

​
Next Steps