Nabdنبض

When an app breaks, Nabd finds out why and fixes it safely.

Nabd نبض is an AI agent for Kubernetes, the system most cloud apps run on. It investigates like an engineer, fixes only with a short list of pre-approved actions, and asks a human whenever a fix isn't safe.

Try it in your browserWhat problem does it solve?
Break something
Nabd dispensary · ns demoRx 0000

No patient waiting. Break something to start.

Pharmacist countersign: not needed yet

Nabd's real rules, running on a simulated copy of our test system. Each line is a step it takes.

Apps rarely break in dramatic ways. They break in small, boring ones.

  1. A small change slips in

    A typo in a version number. A wrong port. A setting renamed. A password deleted by mistake.

  2. The app goes down

    Users see errors. Kubernetes restarts it again and again, but restarting can't fix a wrong setting.

  3. Someone has to dig

    An engineer gets woken up, reads logs and events, finds the one line that's wrong, and fixes it carefully, while users wait.

So why not let an AI fix it?

Because an AI that can run any command can also delete data, expose passwords, or make things worse with a confident guess. Finding the fix isn't the hard part. Trusting the fixer is.

Nabd works like a pharmacist with a short list.

A pharmacist can only hand out what's on the approved list, and some medicines need a doctor's signature. Nabd is built the same way.

Does on its own

  • Go back to the last version that worked
  • Bring back the right number of copies
  • Restart the app to pick up a corrected setting

Asks you first

  • Change where traffic is sent
  • Fix the name of a setting

Never does

  • Delete anything
  • Read, guess or invent passwords
  • Touch anything outside its own area
  • Retry the same fix again and again

If something isn't on the list, Nabd stops and hands it to a human with everything it found. Every change is tested with a dry-run first, checked afterwards, and undone automatically if it didn't help.

One real incident, start to finish

From a live run on our test cluster. Nabd writes a report like this after every incident.

  1. 0 s

    The website stops answering

    The health check gets “connection refused” from the web app.

  2. 4 s

    Nabd finds the cause

    The address in front of the app looks for the label frontend, but the app is labelled web. Nobody receives the traffic.

  3. 4 s

    It proposes the fix and asks

    “Point it back to web, the label it had before.” Changing traffic needs a human, so it waits.

  4. 76 s

    A human approves

    The fix is tested with a dry-run, applied, and checked.

  5. 77 s

    Healthy again

    Every check passes. Nabd's own work took about five seconds; the rest was waiting for the human.

Read the full incident report

How Nabd works

The same five steps every time. Step four is where safety decides, not the AI.

  1. 1

    Notice

    An independent health check sees the app failing.

  2. 2

    Investigate

    It reads what Kubernetes knows: errors, logs, events, settings. Never password values.

  3. 3

    Diagnose

    Proven rules first. An AI model (Claude) only for problems the rules don't recognise.

  4. 4

    Safety checks

    Is the fix on the list? Does it need a human? Does a dry-run accept it? Does the evidence support it?

  5. 5

    Fix and verify

    Apply, re-check, and undo if it didn't work. Or hand over to a human.

Does it actually work?

We broke our test system in 14 different ways and let Nabd handle each one alone. Five of them were kept secret while building it, to prove it handles problems it was never designed for.

Nabd handled 14 of 14, made 0 unsafe changes, and needed the AI model only 2 times.

VersionAll 14 faultsThe 5 secret onesUnsafe changesAI calls
Rules only13 / 144 / 500
AI model only12 / 145 / 5016
Nabd (rules + AI)14 / 145 / 502
Every fault, in plain words
What brokeRight answerRules onlyAI model onlyNabd (rules + AI)
Typo in the app's version numberFix itFixedFixedFixed
Typo in the name of a settingFix itFixedMissedFixed
Memory limit set too lowFix itFixedFixedFixed
Health check pointed at the wrong doorFix itFixedFixedFixed
Health check asks for a page that doesn't existFix itFixedFixedFixed
Traffic sent to a label nobody hasFix itFixedFixedFixed
Asked for 64 processors instead of a tiny sliceFix itFixedFixedFixed
A password was deletedHand to a humanHanded to a humanHanded to a humanHanded to a human
The app was switched offFix itFixedMissedFixed
Traffic sent to the wrong doorsecretFix itMissedFixedFixed
Typo in the start commandsecretFix itFixedFixedFixed
Asked for a kind of server that doesn't existsecretFix itFixedFixedFixed
An admin limit blocks new copiessecretHand to a humanHanded to a humanHanded to a humanHanded to a human
Two different faults at oncesecretFix itFixedFixedFixed

“Handled” means fixed and confirmed by the health check, or correctly handed to a human without changing anything. Raw data: results/.

Words you might not know

Kubernetes
The system most cloud apps run on. It keeps many copies of an app running across many servers and restarts them when they crash.
Pod
One running copy of an app.
Deployment
The instruction “keep N copies of this app running, with this version and these settings”.
Service
The stable address other apps and users call. It forwards traffic to the pods that carry the right label.
Rollback
Going back to the last version that worked.
ConfigMap and Secret
Where an app's settings and passwords are kept, outside the app itself.
Dry-run
Asking Kubernetes “would this change be accepted?” without making it.
Held-out test
Problems kept hidden while building, used only at the end, to prove it handles cases it was not built for.

Honest limits

Break it yourself.

Pick a fault, look around like an engineer, and watch Nabd treat it. Nothing to install.

Try it in your browser