Castrel AI Health Inspection: Find and Close Risk Before Business Impact

When alerts are firing and user requests are already failing, the team needs incident troubleshooting. When the business is still healthy but risk is accumulating, the team needs health inspection.

That period—while there is still time to act—is where Castrel AI health inspection creates value. Castrel AI does not stop at current status. It follows an inspection SOP to evaluate SLOs, alerts, metrics, logs, traces, Kubernetes events, and dependencies; compares them with previous inspection results; distinguishes sustained deterioration from temporary fluctuation; projects which business journey could be affected; and produces a remediation sequence that can be verified.

Health inspection and incident troubleshooting both use logs, metrics, and traces, but they answer different questions. Incident troubleshooting identifies the cause of an impact that has already occurred and restores service as quickly as possible. Health inspection organizes historical trends, capacity headroom, and dependency relationships into a testable risk judgment before impact occurs—making clear when the team needs to act and what must be true before the risk can be closed.

Dimension	Health inspection	Incident troubleshooting
Trigger	Runs regularly or when an early adverse trend appears	Starts after an alert fires, an SLO is missed, or users are affected
Core question	Is risk accumulating, how could it propagate, and when is action required?	What caused the current impact, and how can service be restored quickly?
Completion condition	The root cause or risk is controlled, and a reinspection proves the risk chain is closed	Service is restored, user impact has stopped, and the incident is mitigated

This article uses ShopOne, a representative e-commerce application with 11 business microservices, to show how Castrel AI can identify and close a capacity risk before business impact. Its core checkout journey connects gateway, order, inventory, catalog, payment, and other services through synchronous HTTP calls.

The latest dashboard looked healthy, but Castrel AI classified the application as Warning

At the start of the inspection, ShopOne showed no obvious business problem:

Current business signal	Inspection result
Gateway availability	99.96%
Gateway P95 latency	168 ms, below the 200 ms target
Gateway error rate	0.04%
Service targets	All online
Firing critical alerts	0

A review that ended with this snapshot could reasonably declare the application healthy. Castrel AI continued with three additional tasks: it compared previous inspection trends, examined evidence from expensive calls, and determined whether the current resource change could propagate into the checkout journey.

Castrel AI classified the application as warning. The reason was not an active business failure. It was a capacity window that was shrinking quickly.

Castrel AI calculated the growth rate instead of merely reporting 82.4% disk usage

A single disk value does not determine an action. Utilization at 82.4% may be a temporary peak or a stable baseline. Castrel AI aligned the current result with the previous 12 hours of inspection data and found a sustained rise:

Time	Disk utilization
12 hours earlier	74.2%
6 hours earlier	78.6%
Current	82.4%

Utilization had increased by an average of approximately 0.68 percentage points per hour. A linear projection at the current rate placed the disk at the 90% high-risk boundary in roughly 11 hours and at exhaustion in approximately 26 hours.

Castrel AI did not present that estimate as a guaranteed prediction. Traffic, data volume, and cleanup behavior could change the actual timing. The risk window nevertheless answered a more useful question than “what is disk usage now?”: how much time remained for the team to intervene without business impact.

That changed the priority. The disk had not yet crossed a critical alert threshold, but it could no longer wait for a routine capacity review.

Capacity validation evidence from a simulated failure scenario: abnormal SQL caused MySQL temporary-file writes to surge, pushing the root partition to a high level in the same time window.

Castrel AI crossed metrics, logs, and traces to identify what was driving growth

Expanding the disk based on a trend alone would only delay recurrence. Castrel AI inspected MySQL, service traces, and connection-pool behavior and found several signals moving together in the same window:

Health inspection does not stop at finding that disk utilization is elevated. The team needs to establish the source of resource pressure, its propagation path, and its business consequence before deciding whether it is an observable fluctuation or a risk that requires early action.

Evidence	Current change	Castrel AI judgment
MySQL query P95	Increased from about 1.4 seconds to 5.8 seconds	Database workload was rising rapidly
On-disk temporary-table creation rate	Reached 3.2 times the historical baseline	More query results were spilling to disk
Order connection pool	7 of 10 connections remained active; waiters increased from 0 to 4	The pool was not exhausted, but downstream queries were beginning to hold connections
Tempo slow calls	Inventory and catalog slow calls pointed to the same query pattern	Risk was crossing services in checkout dependencies

The SQL captured in the traces included JOIN user_behavior_log ubl ON TRUE. Without an effective join condition, the query produced a Cartesian-product pattern. As the result set grew, MySQL wrote more temporary data and held database connections for longer.

Root-cause validation evidence from a simulated failure scenario: abnormal SQL, MySQL temporary-file write-failure logs, and the investigation conclusion establish the source of resource pressure.

Castrel AI therefore did not report four unrelated anomalies. It constructed a testable propagation path:

Abnormal SQL multiplies the result set
    → on-disk temporary tables and files continue to grow
    → free disk space falls rapidly
    → slow queries hold database connections for longer
    → the order connection pool queues and times out
    → checkout latency and failures rise

The last two stages had not yet occurred. That is precisely why the chain was actionable. A current-state dashboard could describe each component as it was; Castrel AI combined trend, dependency, and historical evidence to determine how the resource pressure could turn into business risk.

Castrel AI turned the risk judgment into an ordered remediation plan

Castrel AI did not treat “add disk” as the complete answer. It ordered actions according to the failure chain:

Stop the source of growth: inspect the user_behavior_log query generator, remove the ON TRUE Cartesian join, and add the intended business join condition.
Restore safe headroom: remove temporary files generated by the abnormal query and return disk utilization to a safe range.
Reduce recurrence risk: optimize large-result sorting and deep pagination, then add dedicated capacity and growth-rate alerts for temporary-file storage.
Watch the amplifier: monitor active pool connections, waiters, and timeouts without using a larger pool as a substitute for the SQL fix.
Run the same inspection again: verify the result with the same SLOs, windows, and risk chain.

This sequence distinguishes Castrel AI from a fixed-threshold script. A script can notify an operator when disk usage reaches a configured percentage. Castrel AI also explains what is driving growth, which business journey may be affected, what to fix first, and how to verify that the problem has not merely disappeared temporarily.

The second inspection verified risk closure—not merely the absence of alerts

After the team corrected the join condition and removed the temporary files, it ran the same Castrel AI inspection task again. Castrel AI reused the first report’s windows, metric definitions, and risk chain to verify each result:

Verification item	Before remediation	Reinspection result
Disk utilization	82.4%, growing about 0.68 percentage points per hour	63.1%, remaining between 63.0% and 63.4% over the next 6 hours
MySQL query P95	5.8 seconds	220 ms
On-disk temporary-table rate	3.2 times the historical baseline	Returned close to baseline
Order connection pool	7/10 active with 4 waiters	3–4/10 active with no waiters
Gateway availability	99.96%	99.98%

Castrel AI changed the state from warning to healthy, but not because the number of firing critical alerts remained zero. Closure required the disk trend to flatten, abnormal query latency to recover, temporary-file pressure to fall, pool waiters to disappear, and core business signals to remain healthy.

The first inspection created an intervention window. The second produced reviewable evidence that the risk was closed. Health inspection became a continuous process from detection and judgment to action and verification—not a recurring report that no one follows up.

A health inspection delivers an executable risk loop—not an anomaly list

Each Castrel AI health inspection preserves its reasoning and organizes it into a result that teams can hand off, execute, and validate again in the next inspection:

Deliverable	What the team can do with it
Health state and business judgment	Determine whether the application is `healthy`, `warning`, or requires escalation, and whether checkout is affected
Risk window and priority	Decide when a resource may cross its risk threshold and whether action belongs in the current shift, that day, or a later iteration
Evidence chain and root-cause judgment	Understand why the issue can affect the business through evidence from trends, SQL, logs, traces, and connection pools
Ordered remediation plan	Distinguish what to do first, which actions only mitigate the issue, and which measures prevent recurrence
Reinspection criteria and historical baseline	Define when the risk is actually closed and let the next inspection validate this conclusion against the current baseline

In the ShopOne scenario, the team receives more than the monitoring observation that disk utilization is 82.4%. It receives an executable risk loop: checkout is still healthy, but capacity headroom is shrinking; abnormal SQL is driving growth; connection-pool pressure could carry the database problem into ordering; the SQL fix takes priority over disk expansion; and the risk can close only when disk trend, query latency, temporary files, connection pools, and business signals recover together.

Castrel AI remediation and reinspection plan: fix the abnormal SQL first, restore capacity headroom, protect the critical path, and verify risk closure against explicit conditions.

Castrel AI preserves a baseline for each operational domain, then connects them at the business journey

Capacity risk is easy to miss because each operational domain can appear to be below its own threshold when viewed in isolation. Applications, services, hosts, infrastructure, and MySQL face different risks and should not rely on one generic threshold set. Castrel AI can maintain an independent task and historical baseline for each domain, then relate their impact in an application inspection:

Inspection target	What Castrel AI needs to determine
Application	Whether a core business journey is accumulating cross-service risk
Service	Whether errors, latency, restarts, and resource pressure are worsening
Host	How long CPU, memory, disk, and network capacity can support the workload
Infrastructure	Whether cluster events and saturation are affecting more workloads
MySQL	Whether slow queries, connections, temporary tables, and disk behavior could amplify into application failure

The available checks depend on connected integrations, permissions, and inspection rules. The Castrel AI decision model remains consistent: read current state, compare historical trend, relate upstream and downstream evidence, project business consequences, prioritize remediation, and verify closure through reinspection.

Health inspection produces more than a report: an earlier risk decision

In the ShopOne scenario, Castrel AI inspected an application with healthy business signals and no critical alerts. It did not repeat the dashboard conclusion. It performed the work that a dashboard alone could not complete:

Verify that the business is healthy now
    → calculate the disk growth rate and risk window
    → relate abnormal SQL, temporary files, and connection pressure
    → project the propagation path into checkout
    → produce a root-cause-ordered remediation plan
    → reinspect after remediation and verify closure

That is the core value of Castrel AI health inspection: it does not wait for failure and explain the past. It identifies future risk while the business is still healthy and converts fragmented evidence into an operational decision that can be executed, reviewed, and reused. It preserves the reasoning, defines remediation order and closure conditions, and becomes the historical baseline for the next inspection.