Platform overview

StackHeal is an automation platform for infrastructure operations. It sits between the systems that generate operational work — service desks, monitoring, billing, schedules — and the systems that do the work — hypervisors, clouds, servers, backup tools. Its job is to carry a request through a defined, governed sequence and prove what happened.

The components

• Control plane — holds workflow definitions, policy, the action catalogue, tenant configuration and run history.
• Execution runners — perform the actual work against your systems. Runners can be hosted by StackHeal or run inside your own network.
• Action catalogue — the registered operations a workflow is permitted to call. Workflows compose from this catalogue and cannot introduce new capabilities.
• Connectors — maintained integrations that supply context and actions for a specific system, such as a hypervisor API or a service desk.
• Interpretation layer — the AI components that read unstructured requests, correlate signals and match runbooks. It produces structured proposals; it does not hold authority over what is permitted.

How a run flows

1. A trigger fires — a webhook, a monitoring alert, a ticket event, a schedule, an API call or a manual run.
2. The trigger payload is normalised and bound to a tenant, an environment and an asset scope.
3. Interpretation runs where the input is unstructured, producing an intent and a confidence score.
4. Policy is evaluated in code: is this action permitted here, for this requester, on this asset, right now?
5. Steps execute against your systems through registered actions, pausing for approval where policy requires it.
6. Verification asserts the expected end state by reading it back.
7. The outcome is recorded, and written back to the originating system where a connector supports it.

What StackHeal does not do

• It does not store your backups. It coordinates the systems that do.
• It does not replace your monitoring. It consumes its alerts.
• It does not replace your service desk. It reads and updates tickets through its API.
• It does not replace configuration management. It calls your playbooks and records the result.