Fixed by your people once. Fixed by Pulse after that.
When a problem your team has solved comes back, Pulse applies the same approved fix, checks that it worked, and records every step. Anything it cannot fix goes to people.
Four steps from incident to automation
Alert, in seconds
A rule breaches. Pulse raises an alert to the team that owns that system, with the NOC and the operations manager copied.
Your team fixes it
The owner resolves it, records the root cause and the fix, and ticks Teach Pulse.
Four-eyes approval
An operations manager, never the author, approves it and chooses: fix automatically, after approval, or suggest only.
Next time, automatic
Pulse runs the fix step by step and checks the metric has recovered. If it hasn't, the alert escalates to people.
The fix comes from the person who fixed it
Resolving an alert asks for the root cause. The person picks the fix they applied from the catalogue, ticks Teach Pulse, and chooses how Pulse should use it next time.
- Root cause is required before any alert can be resolved
- 14 fix actions in the catalogue, each with its steps and risk level
- Mode: fix automatically, fix after approval, or suggest only
- Limits: maximum runs per day, cooldown, and an optional day-end block
Nothing runs that a second person has not approved
A proposed playbook goes to an operations manager. The person who wrote it can never approve it. Approval-mode playbooks also ask a manager before each run.
- Maker-checker on every learned fix, recorded in the audit trail
- Change history with before-and-after values for every playbook edit
- Suspend, retire or change a playbook at any time
Built so automation can never make things worse
Runs per day and cooldown
Each playbook has its own ceiling, so a fix can never loop.
Blocked during EOD / COB
Optional rule: no automatic action while the day-end runs.
Success is measured
A fix counts only when the metric is back within its threshold.
Two failures, it stops
The playbook suspends itself and asks a manager to review it.
Turn it all off
One switch stops every automatic fix across the bank.
No parallel runs
The same fix never runs twice at once; a fix in progress follows its alert if it escalates.
People when it fails
A failed verification escalates the alert to the on-call team at once.
Every step logged
Who taught it, who approved it, what ran, and whether it worked.
Fourteen actions Pulse can learn
In a live bank, each action calls the bank's own automation: a script, a runbook API or an orchestration tool. The catalogue grows with your runbooks.
| Fix | Area | Risk |
|---|---|---|
| Terminate the blocking database session | Database | Medium |
| Rolling restart of the affected app server node | App servers | Medium |
| Restart the interface connector and resend the queue | Interfaces | Low |
| Route the failing channel to the standby gateway | Channels | Medium |
| Re-run the aborted day-end batch from its checkpoint | Day-end | Medium |
| Extend database storage by 50 GB | Database | Low |
| Run auto-reconciliation and assign the residue to Finance | Suspense | Low |
| Fail over card authorisation to the standby HSM | Cards | High |
| Switch UPI traffic to the secondary link | Payments | Medium |
| Restart the SWIFT FIN link and resend NAKed messages | SWIFT | Medium |
| Switch OTP / SMS traffic to aggregator B | OTP | Low |
| Rolling restart of the mobile API service | Digital | Medium |
| Restart the LMS–core sync job and replay | LMS | Low |
| Raise cash replenishment requests to the cash-in-transit vendor | ATM | Low |
Pulse in 60 seconds
One SWIFT fault, two weeks apart. The first time, your team fixes it and teaches Pulse. The second time, Pulse fixes it before most people notice.
4-EYES · OPS MANAGER
An animated illustration of real Pulse behaviour: the fix steps, approval rule and audit trail are the product's own. Times are illustrative.
See self-healing on your own incidents
We will replay your most common incident on a demo bank and show Pulse learning the fix.