Introducing Reaqt: self-healing automation for Ascender Pro

A disk fills at 12:04 AM. Your nightly job notices at 2 AM. By then it isn't a warning anymore, it's an outage, and someone is awake running the exact playbook you already wrote to fix it.

That gap is the whole problem. Automation is fast once it starts. What's slow is the wait between the moment a condition appears and the moment something decides to act on it. A schedule closes that wait on a timer. A person closes it by hand. Either way, the wait is latency, and you're paying for it.

And you pay for it twice. To catch problems sooner, you poll more often, which means hammering ten thousand healthy machines every few minutes to find the three that broke. Poll less and problems age in the dark. Fast or cheap, pick one. There's no setting that's both.

So the honest description of most fleets is this: your infrastructure knows something is wrong long before anything is scheduled to look.

Reaqt gives Ascender a reflex

Reaqt is the piece that closes the gap. It runs alongside Ascender Pro, and the idea is simple enough: instead of waiting for a schedule or a person, the machine that has the problem triggers the fix itself.

A lightweight listener catches a signal off your fleet, a syslog message or a webhook from another tool. A rule you wrote matches it. The Ascender job that handles that condition runs. No timer. No pager. No one in the middle. The fleet handles its own known problems and heals itself.

Ansible is already good at the what and the how of a task. Reaqt adds the when, and the when is "now, because the thing just happened." Detection was already solved, remediation was already solved, and the fifteen minutes between them was a person reading an alert. That's the reach Reaqt closes, and it's the reflex that turns a run-on-command controller into one that answers on its own.

Worth being clear about what this is not. It isn't monitoring, and it doesn't replace yours. Monitoring tells you something happened. Reaqt can receive events from monitoring and does something about it. Point the tool you already run at a Reaqt rule set, and the alert stops being a notification for a human to read and becomes the trigger for the fix.

How a problem fixes itself

Self-healing has stayed a specialist's project because most tools make you stand up a rules engine, a decision environment, and a controller before you've reacted to a single signal. Reaqt narrows the whole thing to four concepts.

• Listeners catch signals from your fleet. Run as many as you need, wherever they can reach the Reaqt API.
• Rule sets each get their own endpoint and their own token, so every source is scoped on its own instead of sitting behind one shared key.
• Rules match the signal utilizing the same Jinja2 format your playbooks already run on. First match wins, and reshapes its fields into job variables on the way through.
• Providers hand the match off to an Ascender job, a webhook, or a log.

Here's the loop, start to finish, on one real event:

1. A Rocky Linux box fills up and forwards Disk Warning: partition /var at 95% to a listener.
2. The signal lands on that source's rule set, scoped to its own endpoint and token.
3. A rule matches on Disk Warning and reshapes the hostname and message into job variables.
4. Its provider hands those to Ascender, which runs the job template: connects to the host, clears the partition, and closes out.

First you hear of it is a line in the log the next morning. The fix ran itself while everyone slept.

The fix ran at machine speed instead of human speed, which means mean-time-to-repair stopped being capped by who was awake. And the problems that already have a known answer stopped reaching people at all. On-call narrows to the genuinely new failures, the ones that don't have a runbook yet.

Autonomy you can put in production

The reasonable objection to all of this is the one your auditors would raise first: automation that acts on its own is exactly the thing a regulated shop can't allow. If you can't show what it did and control who can change it, it doesn't go to production.

Fair. So the controls aren't bolted on, they're how the thing is built.

Every rule fires a specific job you chose, evaluated in order; first match wins. Automatic never means open-ended. Per-host throttle and burst limits keep a flood of signals from launching a thousand playbook runs, so reacting fast never means reacting recklessly. Every action is recorded with its host, the rule that matched, and the outcome, with dashboards and retention you set. Access is role-based across users and teams, single sign-on included, and provider credentials are encrypted at rest.

Which is the real point of that list: the record isn't a feature you turn on later. It's how the system works. When the auditor asks what your automation did last quarter, the answer is a query, not an archaeology project. Autonomous and provable, in the same tool.

Part of the platform, not another stack

Reaqt runs alongside Ascender Pro and falls under the same support, in the same family as Ledger Pro, so the reflex and the record and the controller share one platform instead of three. Its rules are written in standard Ansible and Jinja2, not a proprietary rules language, so there's nothing bespoke to learn and no separate stack to babysit. The skills that already run Ansible run Reaqt. Self-healing has always been hard to stand up, and that difficulty is exactly what the engineering took on, so what reaches your team is four concepts instead of a rules-engine project. If you want the mechanics, the CIQ docs walk the full setup.

Your automation still runs on a schedule when a schedule is the right answer. But the problems that can't wait for the next run finally have somewhere to go. The machine that needs work asks for it, and the fix you already wrote is what answers.

That's Reaqt. Push, not just pull.

See it on your own fleet. The best demo isn't ours, it's your environment: the signals your fleet already throws off and the playbooks you already run. Book a walkthrough with our automation engineers and they'll show you where Reaqt fits and what it takes to put it to work. Schedule a demo →