Detection with one identity per incident
Conditions you declare are watched on their own schedule. A failure opens one durable incident, so the same failure seen again is the same incident, not a second repair.
In development
Product / operations
DevOps
Find what broke, fix it within the authority you grant, and prove the fix held.
DevOps supervises the systems you connect and corrects failures with actions you have allowed in advance. Each correction is authorized once, carried out at most once within a time limit, checked by a fresh observation rather than by the command's own report, and watched until it holds. A fix that fails is rolled back, compensated, or escalated to a person, and every step leaves a durable record. Its engine is in development; the managed service is planned.
At a glance
- Who it is for
- Teams that run systems which must stay in a known state, and that want failures corrected without handing automation open-ended access.
- What it does
- Watch declared conditions, correct failures with allowed actions, prove the result by observation, and recover or escalate when a fix does not hold.
- How it will be reached
- Planned as a managed service: ApexAPI for software, ApexMCP for agents, and authorized integrations that connect your systems.
- Where it stands
- EngineIn developmentServicePlannedNot publicly hostedNot yet priced
- Next step
- Discuss DevOps Prepare your systems
See an incident
Find what broke. Fix it within bounds. Prove it held.
Every correction follows the same path: one incident, one allowed remedy, one single-use grant, one bounded action, then a fresh observation that decides whether anything was fixed. This is that path for one invented service.
In development The engine that runs it
- 01ObserveThe declared health check for orders-api fails: three probes in a row time out.Fail
- 02Open the incidentOne incident for orders-api, health check failing. This worker claims the system, so no other repairs it at the same time.Owned
- 03Select a remedyThe remedy registered for this condition: restart the orders-api service. It is declared for bounded autonomous maintenance.Tier 1
- 04AuthorizeStanding policy allows the restart on orders-api. A single-use grant is issued for this incident, this change, and this action.Granted
- 05Reserve the changeThe intended change is recorded and one change is spent from the incident's budget before anything runs.Reserved
- 06Act within boundsThe restart runs as a registered action with fixed arguments under a time limit. It exits within the limit.Done
- 07VerifyA fresh check, independent of what the restart reported: health passes, and the declared regression checks (error rate, queue depth) are unchanged.Pass
- 08Stabilize and settleThe stability window holds. The incident closes with its decision history, audit trail, and redacted evidence.Closed
If the fix had not held. Had the check failed again inside the stability window, the fix would not count. A rollback or compensation would run as its own remediation, with its own grant, time limit, and verification; if that did not hold either, the incident would go to a person and stay in attention until handled.
What DevOps covers
An operations controller, not a dashboard.
Keep systems in their intended state without giving automation open-ended power: notice what is wrong, apply only a remedy that is allowed, and call it fixed only when a fresh observation shows that it is.
Remedies in a fixed order
A registered remedy first, then a remedy that already worked on that system, then an AI nomination limited to the actions you allow. When none fits, a person decides.
In development
Authorized, bounded execution
Every action needs a single-use grant from standing policy, runs as a registered action rather than free-form commands, happens at most once per intended change, and is stopped at its time limit.
In development
Verification by observation
A fix counts only when a fresh check shows the original failure cleared and no declared regression appeared. A command that exits cleanly proves nothing on its own.
In development
Rollback, compensation, escalation
Recovery is a full remediation with its own authority and verification. What cannot be recovered or proven goes to a person, with the reason recorded.
In development
Supervision that survives restarts
Incidents, obligations, ownership, and history live in one durable store, so a crash or restart resumes from what was recorded rather than starting over or guessing.
In development
Beyond monitoring
Monitoring reports the failure. DevOps carries it to a verified outcome.
Most tooling stops at the alert and leaves the decision, the permission, the repair, and the proof to a person. DevOps carries a failure from detection to an observed outcome, under rules you set in advance.
| Stage | Typical monitoring and alerting | DevOps |
|---|---|---|
| Detection | A check fails and an alert fires. | A failing condition opens one durable incident. Seeing it again is the same incident, not a new repair. |
| Decision | A person reads the alert and decides what to try. | The controller selects a remedy you registered or allowed, in a fixed order, and records why. |
| Permission | Whoever holds the credentials can run any command. | Each action needs a single-use grant from standing policy, bound to one incident, one action, and one system. |
| Action | A script or runbook step is run by hand. | A registered action runs at most once per intended change, under a time limit. |
| Proof | The alert clears, or the command reported success. | A fresh observation must show the failure cleared and no declared regression, then hold through a stability window. |
| Afterward | A ticket or chat thread, if someone writes one. | A durable decision record, recovery history, audit trail, and redacted evidence, plus a memory of which remedies worked. |
The control loop
From a failing check to a recorded outcome.
Every correction follows the same loop. Authority is decided at one gate, the intended change is recorded before it runs, and the outcome is judged by observation, not by the action's own report.
- 01
Observe
Run the declared check for a system, under a time limit, as a fresh observation.
- 02
Open the incident
Give the failure one durable identity and claim the system, so two workers never repair it at once.
- 03
Select a remedy
Take the first allowed remedy in the fixed order, or escalate when there is none.
- 04
Authorize
Check standing policy and issue one single-use grant for this exact change.
- 05
Reserve the change
Record the intended change and spend its budget before anything runs, so a retry can never repeat it.
- 06
Act within bounds
Run the registered action under its time limit, fenced against a worker that lost ownership.
- 07
Verify
Observe again, independently of what the action reported.
- 08
Stabilize and settle
Watch for regressions through a stability window, then close, recover, or escalate.
Remedy selection
Known fixes first. AI only inside the lines.
Remedies are chosen in a fixed order, and the AI layer is an escalation inside the controller, not the controller. Whatever is chosen passes the same authority, budget, verification, and recovery as any other remedy.
Tier 1
Registered remedy
The remedy you registered for this condition. Your explicit policy always comes first.
Tier 2
Remedy that worked before
A remedy that was verified and stayed stable on this system for this condition. A remedy that failed there is not offered again through memory or AI without an operator's clearance.
Tier 3
AI nomination
When no known remedy applies, an AI model may name one action from the set you allow for that condition. It cannot define a new action, change its arguments, or grant itself permission, and consultations are budgeted per incident.
Tier 4
Escalation
When nothing allowed fits, the incident goes to a person, with the reason recorded and kept in attention until it is handled.
Independent verification
Fixed means observed fixed.
The component that checks a result never relies on the component that produced it. A repair counts only when the system itself, observed again, says so—and keeps saying so.
Four outcomes, not two
A check passes, fails, is unknown, or errors. A timeout is unknown, never an inferred failure or success.
Fresh and bound
Verification takes a new observation after the action settled, tied to that exact change and owner. A cached health reading is not proof.
No credit for the command
The verifier never sees whether the action reported success. Only the system's observed state counts.
Regressions count
Checks you declare for side effects are graded the same way. A fix that clears one problem and causes another is not a fix.
Stability before success
A passing check opens a stability window. Success is recorded only after the window holds; a regression inside it fails the fix and leads to recovery or escalation.
Recovery and escalation
When a fix does not hold.
Undoing a change is treated as seriously as making it. Recovery is planned before the first change runs, and anything that cannot be undone or proven ends with a person.
Declared up front
Each action is declared reversible, compensable, or irreversible, with its recovery action and how to verify it.
Recovery is reserved first
A reversible change is admitted only if capacity for its one recovery is reserved in the same step, so recovery is never refused for lack of budget.
A full remediation
Rollback and compensation get their own authority, change record, time limit, verification, and stability window. A rollback that reports success has not proven anything yet.
Exact where proven
A compensation is recorded as a full restoration only when a restoration check verified it.
Bounded depth
Each change gets at most one rollback and one compensation. A recovery that fails escalates to a person instead of starting another.
Persistent supervision
Supervision that survives a restart.
Operational promises are durable records with due times, not reminders held in memory. A process can stop at any moment and the next one picks up exactly what was owed.
Crash and restart recovery
Work resumes from durable state after a crash. A change that may have happened is observed before anything else is attempted, never assumed either way.
Owed work is tracked
Follow-up checks, stability windows, and declared watches are durable obligations with due times, so nothing depends on a process remembering them.
Declared scope only
DevOps watches the systems and conditions you declare. It does not go looking for systems on its own.
Attention that persists
Failed, blocked, and escalated decisions and failed recoveries are offered to your notification channel until a later decision resolves them or an operator acknowledges them.
Re-decide one exact case
After a failure, an operator can authorize the controller to decide again for that one incident. It grants eligibility only, never budget or authority.
Evidence and memory
A record you can audit, and a memory of what worked.
Machine state, accountability, and reviewer evidence are kept separately, so each can be trusted for its own job.
Decision history
Every state change of every incident and change is appended to a durable history that is the authority on what happened.
Audit trail
Who or what authorized each action, under which policy, and what it did.
Redacted evidence
Evidence packets for people and reviewers, with secrets and sensitive fields removed before anything is written.
Remedy memory
Which remedies worked and stayed stable on which system, and which failed, derived from recorded outcomes rather than from model output.
Access
How customers will reach it.
DevOps is planned as a managed service. Customers will use it rather than run its engine, through the same access layers as the other ApexAi products and an authorized connection to their own systems.
ApexAPI
Applications read incidents, decisions, verification results, and evidence, and make the operator requests their identity allows.
Planned
Explore ApexAPIApexMCP
Agents investigate incidents and retrieve evidence through named tools, with no shell and no authority of their own.
Planned
Explore ApexMCPAuthorized integrations
The connection between DevOps and your systems: what it may observe, and which registered actions it may run there. Supported platforms are not defined yet.
Planned
Operator controls
Acknowledging attention, authorizing one re-decision, and declaring watches exist in the engine as operator acts. How customers will reach them is not decided yet.
Planned
Your systems, your rules
What DevOps will never do on its own.
- DevOps acts only on systems you connect, and only through actions you registered and allowed.
- No caller—person, application, or agent—can name an action for the controller, widen its policy, or grant it authority. A caller can ask; standing policy decides.
- No action is a general shell, and neither operator text nor AI output becomes a command.
- Deployments, migrations, code patches, and backup restores never run autonomously.
- Every correction ends in an observed result, a recovery, or an escalation to a person—never in silence.
Status and pricing
The engine is being finished. The service is planned.
The engine and the service customers will use are separate facts, so they are labelled separately. Nothing here can be bought yet, and no packaging or price is set.
Planned The managed service built on the engine:
- Product
- Planned
- Operations engine
- In development
- ApexAPI
- Planned
- ApexMCP
- Planned
- Hosted service
- Not publicly hosted
The DevOps operations engine (detection, authorized correction, independent verification, recovery, supervision, and evidence) is in development and finishing its qualification. The managed service customers will use, with its ApexAPI and ApexMCP access and the integrations that connect a customer's systems, is planned: there is no sign-up, customer endpoint, or hosted service.
- Still to qualify in the engine: restore detection, verified backup and restore, full process containment, store capacity limits, and a qualified release.
- The engine has a read-only MCP inspection interface for ApexAi's own operators. It is internal tooling, not a customer service.
- Supported customer platforms and integrations are not defined yet, and DevOps has no product plugin: it is the operations product itself.
Not yet priced
DevOps is planned as a managed service that customers pay ApexAi to use. No plans, prices, or metering are set, because the service is not built yet.
| Paid to | Covers | How it works | Price |
|---|---|---|---|
| ApexAi | Access to the DevOps service | Supervision, correction, verification, and evidence for the systems you connect. Plans and how usage is measured will be decided with the service. | Not yet priced |
| Your infrastructure providers | The systems DevOps supervises | The hosting, cloud, and other providers that run your own systems keep billing you directly. ApexAi does not resell them. | Billed by your provider |
Final plans and public access details will be published before launch. Follow launch updates
Bring the systems that must stay in a known state.
DevOps is not available yet: there is no sign-up, customer endpoint, or hosted service. Tell us what you run and what a good repair looks like for it.
Decide these before you connect a system
Choose the systems in scope
List the systems you want supervised, and who owns each one today.
Define healthy
For each system, write down the checks that prove it is working, and the side effects a fix must not cause.
Name the allowed fixes
Which corrective actions are acceptable, which can be undone, how, and which must always wait for a person.
Decide who is told
Where attention should go when a fix is blocked or a recovery fails, and who may acknowledge it.