Skip to content
Get started

Operational recovery planning

Build a reviewable recovery sequence from maintained process dependencies and tasks, explicit resources, outage simulations and RTO/RPO targets.

Input

Critical operational and IT processes: id,name,criticality,rto_minutes,rpo_minutes,backup_at,owner,description P1,Order database,high,60,60,2026-11-03T08:30:00Z,Database team,Restore the maintained order database before restarting order …

Result

The database task is planned for minutes 0–30 and order intake for minutes 30–50 using the single recovery operator. Both planned finishes meet the supplied 60- and 120-minute RTO targets. The supplied backup age is 30 minutes against a …

Recovery planning starts with maintained operational facts: process dependencies, tasks, durations, resources and target times. The AI selects substantive process and task passages for review. The server calculates affected downstream processes, a capacity-aware sequence and unresolved blockers. Planned completion, RTO comparison and backup-age evidence stay distinct from a claim that recovery has succeeded.

Your texts, pages and images are processed on our own servers in the EU. Trust Center

Try it now Pricing

Who it is for

Operational and IT continuity teams preparing a tabletop exercise from maintained internal recovery procedures. This is not a live incident controller, a medical emergency guide or an evacuation planner. Approved internal runbooks and responsible specialists remain necessary.

Typical uses

  • Simulate a failed process and trace its dependent processes.
  • Reduce resource capacity or mark a recovery resource unavailable.
  • Compare planned finish against RTO and supplied backup age against RPO.
  • Reveal dependency cycles, missing tasks and blocked downstream work before a tabletop review.

Example

Input

Critical operational and IT processes: id,name,criticality,rto_minutes,rpo_minutes,backup_at,owner,description P1,Order database,high,60,60,2026-11-03T08:30:00Z,Database team,Restore the maintained order database before restarting order intake. P2,Order intake,high,120,60,2026-11-03T08:30:00Z,Service team,Order intake requires the order database to be available. Maintained dependencies: id,from,to,evidence L1,P1,P2,Order intake reads and writes the order database. Maintained recovery tasks: id,process,sequence,duration_minutes,resource,units,instruction T1,P1,1,30,R1,1,Restore the approved database backup and record the validation result. T2,P2,1,20,R1,1,Restart the maintained order intake service after database verification. Recovery resources: id,name,capacity R1,Recovery operator,1 Simulated failed process IDs: P1 Explicit UTC reference time: 2026-11-03T09:00:00Z Planning horizon in minutes: 480 Recovery scheduling priority: Supplied criticality Available resource capacity (%): 100 RTO safety margin in minutes: 0 Backup-age policy: Warn about backup gaps Criticality filter: All Maximum review selections: 10 Quotation detail: Detailed Display order: Scheduled start

Result

The database task is planned for minutes 0–30 and order intake for minutes 30–50 using the single recovery operator. Both planned finishes meet the supplied 60- and 120-minute RTO targets. The supplied backup age is 30 minutes against a 60-minute RPO. These are planning comparisons, not proof of a usable backup or successful restoration.

A fixed example, shortened. Real results are AI-generated: please check them.

Price and limits

Price
usually 1–3 credits
Available with
Free, With package
Input limit
One page with up to 100,000 characters of HTML

Privacy

Processed on our own servers in the EU (Poland). Inputs and results are deleted after 7 days (Free) or 30 days (packages), or right after you see the result if you choose not to store them. Images are deleted right after processing.

In the API

Tool name: recovery_plan. Create a job with POST /api/v1/jobs and fetch the result with GET /api/v1/jobs/{id}. You find your API key in your account.

curl -X POST https://do4u.eu/api/v1/jobs \
  -H "Authorization: Bearer d4u_…" -H "Content-Type: application/json" \
  -d '{"tool": "recovery_plan", "url": "https://example.com/"}'

Full API documentation →

Questions and answers

Are tasks executed or generated freely?

No. Only maintained task instructions can appear as exact quotations. The model cannot add a command, recovery task or resource. Nothing is executed or sent to an external service.

How are dependencies and capacity handled?

An affected process waits until every affected prerequisite is scheduled. Its tasks follow their supplied sequence. Resource reservations respect effective whole-unit capacity and allow parallel work only when capacity permits. Cycles, missing tasks and infeasible resources remain blockers; downstream work cannot skip them.

Does meeting RTO or RPO prove recovery?

No. RTO compares the estimated finish plus the explicit margin with a supplied target. RPO compares the reference time with a supplied backup timestamp. Neither checks backup integrity, actual data loss or successful restoration. Unaffected prerequisites are assumed available, so incomplete dependency data can invalidate the plan.

Is my text stored?

Only as long as needed: 7 days on Free, 30 days with a package – or not at all if you choose not to store it. Processing happens on our own servers in the EU (Poland).

Can I use the result right away?

Results are AI-generated. Please read them before you publish or send them.