Which events does Autoheal act on?

Hung scheduled tasks, integration queue backlogs, certificate expiries and agreed retries. Each is a register entry with its own condition, ceiling and verification.

How many of our incidents will be automatable?

A minority at first. Start with the three conditions your team handled most often last quarter, where the steps are stable and the verification is unambiguous.

What happens if an automated action makes something worse?

The playbook takes only its granted attempts, touches only what its scope names, and must prove the condition cleared. Otherwise it stops, reverses its own action where the runbook defines a reversal, and pages a person with the state before and after.

Can we add our own playbooks?

Yes, alongside the curated ones. Playbooks are versioned, reviewed, and approved through your change process before they run unattended.

Do we need Sentinel and Diagnose?

Sentinel and Diagnose supply what to act on and why. Autoheal also acts on signals from existing monitoring where those signals name the condition precisely enough.

MaxIron Portal

For repeating Maximo problems, run the recovery you already use.

Name: MaxIron Autoheal
Brand: MaxIron
Availability: InStock

Autoheal handles named conditions such as a hung scheduled task, a queue that has stopped draining or a certificate approaching expiry. It runs an approved recovery, checks the result and writes the incident record. Unfamiliar conditions and actions requiring judgement go to the engineer on call.

Review Autoheal against one agreed recovery See Sentinel

Autoheal is provided through MaxIron Portal for agreed recovery actions. Scope and price depend on the environments, runbooks and approval controls included. Quote on request.

One approved recovery condition

Condition: A named task hung on a named environment for over fifteen minutes, inside the monthly patch window.
Action: The five runbook steps your engineers already run at 03:00, in that order.
Ceiling: One attempt. No second try and no variation.
Verification: Generation completed, and the work order count sits inside the range for a Sunday.

Contents 7 sections

01 Recovery conditions Six repeating problems and what Autoheal may do for each.
02 Stand-down incident At 02:51, two attributes fall outside the approved condition.
03 Getting on the register Match the condition, run the steps, check the result.
04 Boundaries Acts only on conditions agreed in writing.
05 Questions Which events, how many incidents, and custom playbooks.
06 Related products Sentinel, Diagnose and Change Control.
07 Next step See Autoheal with three months of out-of-hours pages.

Contents

Recovery conditions
Stand-down incident
Getting on the register
Boundaries
Questions
Related products
Next step

Recovery register

Six repeating problems, and what Autoheal may do for each

Each entry names the condition, the permitted recovery steps, the attempt or time limit, and when an engineer is alerted. Entries B1 and B2 require a person to investigate.

Overnight preventive maintenance generation hung after the patch window

Automated, narrowly

What the playbook does: The five runbook steps engineers run at 03:00: clear the hung task, restart the job, watch it complete.
Where the ceiling is: One attempt, inside the monthly patch window.
Is a person woken: Only if verification fails

Ninety minutes by hand, four of them the fix. About five minutes by playbook. Illustrative times.

Outbound integration queue that has stopped draining

Automated where the retry is agreed

What the playbook does: The agreed retry sequence for that named flow, on that environment only.
Where the ceiling is: The granted attempt count, and nothing outside the named flow.
Is a person woken: If the backlog is still static after the granted attempts

Certificate approaching expiry on a named endpoint

Automated only where your policy permits it

What the playbook does: Where policy allows machine rotation, the agreed steps run and the new certificate is confirmed. Where it does not, the playbook gathers state and stops.
Where the ceiling is: Whatever your policy says, which is often the evidence and no further.
Is a person woken: Always, where policy reserves credential changes to a person

Scheduled task that did not start inside its window

Automated, narrowly

What the playbook does: The agreed start sequence for that named task on that named environment.
Where the ceiling is: Inside the window only. A closed window is a decision about the day ahead.
Is a person woken: If the task will not start, or the window has already closed

The same task hung, outside the agreed window, with an unfamiliar session count

No playbook applies

What the playbook does: Nothing. Two attributes fall outside the approved condition, so Autoheal stands down.
Where the ceiling is: An unmatched condition is preserved for the engineer to investigate.
Is a person woken: Always

Direct business-data edits, irreversible actions and decisions requiring judgement

Never a candidate

What the playbook does: None. These belong with Sentinel, Diagnose and an engineer.
Where the ceiling is: These actions remain outside unattended recovery.
Is a person woken: Always

Every event reaches the incident record, stand-downs included. Your register carries your own conditions.

Entry B1, on one night

02:51: the task requires an engineer

Two attributes put this night in entry B1, not entry A1.

02:51

The overnight task is hung on the same environment as entry A1, and the page looks identical.

Written The signal, and the entry it resembles.
02:51

The patch window closed at 02:00, and the database session count sits above the agreed range.

Written Both mismatched attributes, by name.
02:52

Autoheal acts on nothing and pages on-call with the state it gathered.

Written The stand-down, and the reason no playbook applied.
03:04

The engineer takes it to Diagnose rather than the A1 runbook.

Written The human decision, on the same incident record.

In early rollout the stand-down is the most common outcome. A register scoped too widely produces fewer of them.

Getting an entry onto the register

Approve the recovery steps and verify every run

The operations lead approves the exact condition, recovery steps and attempt limit before Autoheal runs. Each stage proceeds only when the previous result meets that agreement.

01

Agree the condition

Named signal, environment, threshold and window, approved before anything runs unattended.

Owner Your operations lead, with MaxIron Typically 1 to 2 weeks per entry
02

Agree the action and its ceiling

The steps your engineers already run by hand, the attempts granted, and the point at which the playbook stops and pages.

Owner Your on-call engineers Typically Same window
03

Match, or stand down

Every live event is compared with the agreed condition. Anything unrecognised pages a person.

Owner Autoheal Typically Seconds
04

Act, then verify

The steps run, then the condition is re-tested. A failure pages with the state before and after.

Owner Autoheal Typically Minutes
05

Record it, then widen it on evidence

What fired, why it matched, the steps and the outcome go into the incident record at the time. Widening a playbook goes through Change Control.

Owner Your change process Typically Per review cycle

Assess one recurring condition

Five controls for unattended recovery

Use the out-of-hours alert your team handled most often last quarter. Every statement must hold before the condition becomes a candidate for Autoheal.

1
The condition can be named as a signal on a named environment, with a threshold and a window.
2
The steps your engineers run are the same every time, in the same order.
3
A check proves the condition cleared, and reading it needs no judgement.
4
Nothing in those steps touches business data or takes an irreversible action.
5
Your change policy permits a machine to take those steps on that environment.

If you stopped early

The condition stays with a person, and the work is describing it precisely enough to reach statement five. Most start here.

If every statement held

It is a candidate for a register entry, with the condition, ceiling and verification written during scoping.

Scope and boundaries

Where Autoheal stops and a person takes over

The three limits that make unattended remediation acceptable in production.

It acts only on conditions agreed in writing

No learning on the fly, and no acting on a near match. A playbook is a written agreement about one condition, one action, one ceiling and one verification.

It does not work out what is wrong

Resolving repeat failures across Maximo and MAS estates MaxIron operates, closing the loop from Sentinel and Diagnose, with approvals through Change Control and Cloud Manager on managed hosting. An unexplained event is not a candidate for a register entry: detection belongs to Sentinel, cause to Diagnose, and the decision to an engineer.

Some conditions stay with a person permanently

Direct business-data edits, irreversible actions and decisions requiring judgement remain with a person. Higher-impact playbooks request approval through Change Control before they run.

MaxIron Autoheal, frequently asked questions

Which events does Autoheal act on?: Hung scheduled tasks, integration queue backlogs, certificate expiries and agreed retries. Each is a register entry with its own condition, ceiling and verification.
How many of our incidents will be automatable?: A minority at first. Start with the three conditions your team handled most often last quarter, where the steps are stable and the verification is unambiguous.
What happens if an automated action makes something worse?: The playbook takes only its granted attempts, touches only what its scope names, and must prove the condition cleared. Otherwise it stops, reverses its own action where the runbook defines a reversal, and pages a person with the state before and after.
Can we add our own playbooks?: Yes, alongside the curated ones. Playbooks are versioned, reviewed, and approved through your change process before they run unattended.
Do we need Sentinel and Diagnose?: Sentinel and Diagnose supply what to act on and why. Autoheal also acts on signals from existing monitoring where those signals name the condition precisely enough.

Review three months of out-of-hours alerts with Autoheal

We sort them into problems with stable steps, problems that need Diagnose first, and problems that stay with a person. Then we draft the condition, the limit and the check for the first candidate.

Bring this to the first call

Three months of out-of-hours pages, with the time each one landed
The runbook your engineers reach for at 03:00, however stale the page is
The actions your change policy will never allow a machine to take
Who signs off a playbook, and the evidence they need in order to sign