Kibana Anomaly Detection Skill for Agent-Driven RCA

Where this fits

Your agent is on call for a production incident. The user asks: "What broke? Which entity is anomalous?". Without a skill, it would either guess from raw logs or hand you a Kibana URL. With kibana-anomaly-detection, the agent reads .ml-anomalies-* results directly, identifies the culprit entity, and explains the score — all from a single prompt. This skill turns your agent into an ML operations analyst, not just a log grepper.

Why agents benefit

• Root-cause attribution: Agent queries anomaly results and pinpoints the exact influencer (e.g., a specific host, user, or API endpoint) driving the anomaly, not just a generic spike.
• Score explanation: When asked "why is this score high?", the agent inspects model behavior, explains renormalization effects, and distinguishes genuine anomalies from model drift.
• Job lifecycle diagnosis: If a datafeed stops or a job hits hard_limit memory errors, the agent fetches job stats and suggests concrete fixes (e.g., increasing bucket span, pruning models).
• Operational control: The agent can list, start, stop, or update ML jobs via REST APIs, enabling automated remediation workflows without human UI interaction.
• Serverless-ready: Uses POST /.ml-anomalies-*/_search which works on Elastic Cloud Serverless, so the skill stays valid across deployment models.

Practical scenarios

Incident triage with influencer breakdown

A user reports "latency spiked at 14:32". The agent runs an anomaly search, finds a high anomaly score on the service.name influencer, then drills into the top entity — checkout-service — and presents the score, typical/actual values, and a confidence band. No manual Kibana navigation needed.

Explaining a sudden score drop

After a model update, an entity's anomaly score drops unexpectedly. The agent retrieves job stats, detects a renormalization window, and explains that the baseline shifted due to new data, correctly attributing the drop to model recalibration rather than a real improvement.

Fixing a stalled datafeed

A datafeed stops with hard_limit memory errors. The agent fetches job memory status, identifies the offending model size, and recommends a memory limit increase or a job restart with a smaller bucket span — then optionally performs the operation via the ML REST API.

Add it to your agent workflow

Install the skill with a single command:

npx skills add elastic/agent-skills --skill kibana-anomaly-detection

Then prompt your agent naturally:

User: "Check the ML job `web-traffic` — why did the datafeed stop at 3 AM?"
Agent: (calls skill) Fetches job stats, sees `hard_limit` memory error, explains bucket span issue, offers to restart with adjusted settings.

The skill reads from .ml-anomalies-* indices and ML REST APIs, so your agent works with live data — no extra connectors needed.

Compare before adopting

Before committing, evaluate against other anomaly detection skills or custom scripts. Check: does it handle both results and job state? Is it compatible with your Elastic version (8.x–9.x, Serverless)? Look at the README for evidence of maintenance — recent commits, version 0.3.0, and the universal: true flag suggest broad applicability. Also consider whether your team needs the full lifecycle management or just read-only analysis; the skill covers both, but you might prefer a lighter custom routine.

Why it is worth tracking

With 568 stars and official Elastic authorship, this skill shows strong community trust and active upkeep. It addresses a real gap — most agents can query logs but lack ML-specific reasoning. As anomaly detection becomes standard in observability, having a skill that speaks the ML domain fluently is a competitive edge. Track it if you're building agents that handle production monitoring, on-call triage, or automated incident response. For more agent skills, see OpenAgentSkill.