What IntelliTune's 200+ auto-remediation patterns actually resolve without a human, what they deliberately leave alone, and how to reason about the economics once a fleet runs into the hundreds of clusters.
Kubernetes was designed to be self-correcting at the primitive level — a crashed pod gets restarted, a node that fails a health check gets cordoned. What it was not designed to do is understand why a pod keeps crashing, whether a HorizontalPodAutoscaler is thrashing because of a genuine traffic spike or a misconfigured target, or whether a StatefulSet's rollout is stuck because of a resource quota nobody remembered to raise. Those are the incidents that page an on-call engineer at 2am, and they are overwhelmingly the same handful of patterns repeating across clusters, namespaces, and weeks.
That repetition is the opening this paper is about. A pattern that a platform team has seen, diagnosed, and fixed by hand a dozen times is a pattern that can be codified, verified, and handed to automation — provided the automation can prove, each time, that it correctly identified the cause before it acts.
IntelliTune is Applicare's remediation engine. It sits downstream of the causal entity graph and ArcIn's root-cause analysis, and it acts only once a specific, known failure pattern has been matched with enough confidence to act on — not on a bare anomaly signal. In the Kubernetes context, that includes crash-loop pods traced to a specific misconfiguration, HPA scaling decisions corrected against real target metrics, node-level resource pressure relieved by rescheduling before an eviction cascade starts, and stuck rollouts unblocked once the blocking condition is identified.
Each of those is one of the 200+ patterns IntelliTune ships with. Execution, once a pattern is matched and gated by policy, takes about 400 milliseconds — orders of magnitude faster than the round trip of an engineer reading a Slack alert, opening a terminal, and running kubectl by hand.
The distinction that matters: IntelliTune does not react to symptoms in isolation. It acts on a diagnosed cause, traced through the entity graph, with a specific known fix — the same reasoning chain a senior SRE would use, compressed to under half a second.
Every IntelliTune pattern follows the same shape, regardless of which Kubernetes failure it targets:
That verify-or-roll-back step is what separates a remediation engine from a script that fires once and hopes. It is also why "self-healing" is a meaningfully different claim from "auto-restart" — the pattern doesn't just take an action, it confirms the action worked.
The following sequence is representative of how IntelliTune handles a memory-pressure incident on a production Kubernetes node — the same class of incident described in Applicare's SAP HANA deployment, where 14 such incidents were auto-resolved in a single customer's first month without a page reaching the on-call Basis team.
No war room, no Slack thread, no engineer paged. The incident exists in the system as a closed, fully logged record — which matters as much for building trust in the automation as the remediation itself.
Equally important is what doesn't happen automatically. IntelliTune acts only on patterns it has a verified signature for, gated by policy per cluster and namespace. A failure mode outside that library — a novel bug, an unfamiliar cascading dependency failure, anything the entity graph can't trace to a specific known cause with sufficient confidence — is surfaced to ArcIn for root-cause analysis and to a human for a decision, not guessed at.
| Situation | IntelliTune's behavior |
|---|---|
| Known pattern, high confidence | Acts automatically, within policy gates, and verifies the fix |
| Ambiguous signal, low confidence | Escalates to ArcIn for root-cause analysis; no unattended action |
| Novel failure, no matching pattern | Surfaced to on-call with full causal context; nothing acted on unattended |
| Pattern matched, action doesn't resolve it | Action is rolled back automatically and the incident is escalated |
A single customer's SAP HANA environment saw 14 memory-pressure incidents auto-resolved in one month, with no page reaching on-call. That is one pattern, in one workload type, at one customer's scale. Extend that same order of magnitude across a large enterprise fleet — hundreds of clusters, thousands of services, running the full library of 200+ patterns rather than one — and the resulting annual auto-resolution count compounds into the hundreds of thousands. We use this reasoning, not a measured aggregate figure, to illustrate why the economics of self-healing change qualitatively once a platform team is running Kubernetes at genuine scale rather than a handful of clusters.
The purpose of walking through that math is not to claim a specific number as fact — Applicare does not publish an aggregate cross-customer auto-resolution count — but to make the underlying point concrete: at a handful of clusters, self-healing saves an engineer a few tickets a week. At fleet scale, the same 200+ patterns are the difference between an on-call rotation that is survivable and one that isn't.
Unattended remediation only earns trust if it fails safely. IntelliTune's pattern library is scoped per cluster and namespace by policy — a pattern approved for unattended execution in a staging environment is not automatically approved in a production payments cluster. Every action IntelliTune takes is verified against the signal it was meant to resolve, and every action that doesn't resolve that signal is rolled back automatically rather than left in an unknown state.
Teams typically start with IntelliTune's pattern library running in observe-only mode against their entity graph, reviewing what it would have done against a few weeks of real incident history before enabling unattended execution — first in non-production, then narrowly in production for the pattern classes the team is most confident in. Root-cause visibility through ArcIn and ArcIn's causal entity graph is available from day one regardless of how much of the remediation library is switched on.