Detection, root cause analysis, automated remediation and forecasting for production estates — deterministic by design, with large language models as an optional layer that is never load-bearing.
A single failure rarely produces a single alert. A database that slows down produces connection-pool warnings on every application server that talks to it, latency alerts on every endpoint that queries it, transaction SLA breaches for every business flow that depends on those endpoints, and error-rate alerts wherever timeouts turn into exceptions. One cause, dozens of alerts, all arriving within a minute and all looking equally urgent.
Two things follow. The first is triage cost: somebody has to work out which of those alerts is the origin. The second is worse — the origin is often the quietest signal in the storm, because the systems shouting loudest are the ones furthest downstream. Teams learn to distrust their own alerting, thresholds get raised, and the next real incident is found by a customer.
Monitoring tools are good at telling you that something is wrong. They are far less good at telling you what is wrong, why, and what to do about it. The gap is filled by engineers, at three in the morning, correlating dashboards by hand. Applicare AI closes that gap: it detects conditions across the whole estate, groups the resulting alert storm into a single incident, explains the cause with the evidence that supports it, offers the fix where the problem is reported, and forecasts the capacity problems that have not happened yet. The analysis engine is deterministic — the same evidence always produces the same answer, and every conclusion can be audited. Large language models are supported but optional, and the product is fully functional without them.
Applicare ships 148 detection rules spanning applications, servers, databases, JVMs, containers, Kubernetes, virtualised infrastructure and security. They are maintained as part of the product rather than assembled by each customer, and they read the underlying tables directly, per host, at full resolution — no pre-aggregation that averages a hot server into invisibility.
Rules encode conditions that are known to matter — a stopped IIS site, a saturated connection pool, a statement consuming most of an application's database time, a disk trending to full.
IntelliSense scan adds 29 on-demand deep checks: slow and blocked SQL, GC overhead, heap growth, processor-queue saturation, TCP and process-count anomalies, alert storms, SIEM coverage gaps and more. Each check declares the schema it needs and is skipped silently where a data source is absent, so the same engine works against any estate.
Anomaly detection compares a live window against that metric's own baseline using mean and standard deviation, so a server is judged against its own normal rather than an estate-wide threshold that suits nobody.
Alongside these are detectors for failures that are genuinely hard to catch by hand: heap leaks identified from growth across garbage-collection cycles, stuck threads, JDBC connection leaks traced to the acquiring code, and SQL statements flagged as vulnerable.
Every one of the 113 alert types Applicare understands is classified into one of 20 families, each carrying a cause-or-symptom flag, a confidence floor and a precedence rank. Ten families describe causes — service unavailability, database resource pressure, host saturation, disk exhaustion, JVM pressure, container instability, connection-pool exhaustion, middleware backlog, connectivity faults and traffic spikes. Ten describe symptoms: latency, error rates, transaction failures and SLA breaches, user-experience degradation.
Causes outrank symptoms, so the alert that represents the origin is promoted and the alerts it produced are folded underneath it. The operator sees one incident with its consequences attached, rather than thirty rows of equal weight.
"The correlation path is deterministic and rule-based. No model decides what caused what — which is why the grouping can be explained to an auditor and reproduced tomorrow."
Operational and security alerts are explicitly marked non-correlatable so that, for example, a licence warning or a directory-service event never pulls an application incident off course.
Root cause analysis is delivered by a registry of analysers. Nine are specialised — IIS, databases, host platform, Kubernetes, virtualisation, security, JVM out-of-memory, failed transactions and agent liveness — and a generic analyser handles everything else, so no alert type is ever left without an explanation.
Each incident is analysed twice. The cause phase runs shortly after the alert fires and answers why it happened. The resolution phase runs when the condition clears and records how it cleared — automatically remediated, manually fixed, or self-recovered. The second phase matters more than it first appears: it is what allows the story to survive the alert, so the question "what happened last quarter?" has an answer.
Behind the analysers sit 13 investigators, each running the targeted checks a specialist would run by hand: heap pressure, CPU pressure, memory pressure, GC overhead, slow SQL, blocked SQL, database pool exhaustion, slow HTTP, API traffic, agent activity, coincident alerts and scan findings. Their output is assembled into a narrative rather than a list of numbers.
Every conclusion carries what Applicare checked, divided into three categories: what supported the finding, what was ruled out, and what was merely coincident. Confidence is explicit. Where the evidence does not identify a side, Applicare says the boundary between two tiers is at fault rather than blaming one of them — because sending an engineer to investigate a healthy component is worse than admitting the limit of what the data shows.
For incidents that sit on the request path, Applicare draws the measured topology: the tiers a request passes through, the call volume and latency of each hop, the share that failed, and the worst case observed. Every hop is drawn because the agent recorded it. Nothing is inferred and no edge is assumed.
A measured request path shows, for example, an application calling two databases, with the boundary carrying the fault marked and impact traced back against the traffic to the tiers that depend on it.
Detection and explanation are only worth the time they save, and time is saved at the point of action. Where Applicare knows how to correct a condition, the fix is offered on the issue itself — not on another screen, and not as a script to copy.
Applicare forecasts each tracked metric using nine models in parallel: ARIMA, Holt-Winters, Kalman filtering, Prophet, linear and robust linear regression, a bivariate model, a multi-seasonal model and a seasonal baseline.
Rather than choosing a winner, the models are back-tested — each is trained on all but the most recent observations, scored against that held-out tail, weighted by inverse error, refitted on the full series and combined. On metrics with moderate variance such as throughput and response time this blend outperforms winner-takes-all selection by 8–15%, because models that score similarly contribute complementary information instead of one arbitrarily winning a close race.
Each metric's seasonal period is detected from its own history by autocorrelation — weekly, monthly or bi-monthly — rather than assuming a fixed weekly cycle, and a holiday calendar prevents known low-traffic days from being read as decline. Forecasts are delivered as a status, a plain-English recommendation and the sibling metric most likely driving the trend, so the output is a decision rather than a chart.
Applicare can optionally use a large language model — Claude or OpenAI — to turn structured evidence into a written narrative. This is deliberately a thin layer at the top of the stack, and three properties define it.
Where a model is enabled, Applicare captures the difference between what the model concluded and what the rules already knew. That delta is held as a candidate, confirmed against what subsequently happened, and only after confirmation is it applied to future incidents — deterministically, as knowledge, not as a fresh model call. The system gets better at your estate over time without becoming dependent on a model being available.
The same analytical approach extends to security telemetry. Applicare ingests syslog, normalises and enriches events, imports Sigma detection rules, matches indicators of compromise against threat intelligence, and correlates security findings with the performance picture — so a connection-load anomaly and an authentication spike can be recognised as one story rather than two unrelated tickets.
| Before / After | What changes |
|---|---|
| Alert volume | Storms arrive as single incidents with the origin identified and consequences attached. |
| Time to cause | The investigation an engineer would perform by hand has already run, with its evidence attached. |
| Time to fix | Remediation is offered where the problem is reported; recurring problems can correct themselves. |
| Surprises | Capacity exhaustion is forecast with dates and named drivers rather than discovered at peak. |
| Defensibility | Every conclusion shows the evidence, the confidence and the measurement window behind it. |
Figures in this paper describe the shipping product and were taken from the Applicare codebase and a running installation. Detection rule and alert type counts reflect the current release and grow between versions.