Job runbooks-drafted-from-past-incidents-and-tabletop-tested · revised 12 October 2026
Runbooks drafted from your past incidents and walked through in a tabletop test
Up to five runbooks drafted from your past incidents, every step cited to the record or marked proposed, each walked through by your engineer on scenario cards. A document, not an on-call assistant.
You might be seeing
- The same outage was fixed three times by trial and error
- Only one person knows the order of restart steps
No passwords, keys, card details or admin invites needed to start.
What usually happened
Runbooks that nobody tested fail at the worst moment. Writing them from past incidents takes time, and a model can add steps that were never part of any real fix. A live assistant with production access would be a different risk altogether.
Who it’s for: A small team whose incident knowledge lives in a few people's heads and old threads.
Usually starts when: The person who always fixes it is away, or the third repeat of the same outage showed that nothing was written down.
The result: Up to five runbooks are drafted from your past incidents, and every step cites the record it came from or is marked "proposed". Each runbook is walked through by your named engineer on three scenario cards, one of them written by your engineer, who marks each step clear, unclear or wrong. At least 90% of steps must be clear and none wrong, and nothing is executed on your systems.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The runbooks
- The source index
- The scenario cards
- The walk-through results
Included
- Up to five past incidents and the exported thread, logs and fixes for each
- One runbook per incident type with steps, checks and who to ask
- Each step cites its source or is marked proposed
- Three scenario cards per runbook, one written by your engineer, and a walk-through by your engineer
- Commands listed as read-only or marked "not run"
Not included
- A live on-call assistant, paging, or any access to production
- Running any command on your systems
- Round-the-clock cover
- Credentials, tokens or secrets in the runbooks
- Deciding severity levels or escalation policy
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every runbook step cites a message, log line or fix from the supplied records, or is marked proposed, checked by script.
Evidence: The script check and the source index.
In a walk-through of three scenario cards per runbook, one of them written by your engineer and not shown to us until the walk-through, at least 90% of steps are marked clear and none is marked wrong. You may agree a higher share in writing beforehand. It describes these cards, not every incident. The repeat uses a fresh card written by your engineer.
Evidence: The marked scenario cards, including the one your engineer wrote.
No runbook holds a credential, token or secret, shown by a scan.
Evidence: The scan output.
Every command is listed as read-only or marked "not run".
Evidence: The command list with its marks.
Sign-off. Your engineer and runbook owner read the results and sign off in writing. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- Up to five past incidents with exported records, with personal data removed
- A named engineer who does the walk-through
- Runbooks that will be kept by a named owner
We stop and tell you if
- The records hold personal data or a possible notifiable breach
- No past incident record exists to draft from
- The walk-through engineer is not available
What could go wrong
The job writes documents and runs nothing on your systems. Our copies of your records are deleted when the job ends.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A runbook step was never part of a real fix and does harm when followed. | Every step cites its source or is marked proposed, and your engineer marks each step in the walk-through; zero wrong steps are allowed. |
| The runbook goes stale. | A named owner is agreed, and the date of each source is on the page. A monthly update is a separate service. |
| Records carry instructions meant for the model. | The incident thread, logs and documents are treated as data: the model gets the text and returns drafts a script checks, with no tools, no network and no secrets. |
A separate automated reviewer checks the work before hand-over. Your named engineer walks through the scenario cards and marks each step. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the incident types, the sources and the walk-through marks
- Receive exported records with personal data removed
- Draft each runbook; cite a source for every step or mark it proposed
- Write two scenario cards per runbook; your engineer writes the third
- Separate automated reviewer checks citations; your engineer walks through the cards
- Fix unclear or wrong steps, repeat the walk-through, then hand over
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To keep the runbooks current, a monthly review can be quoted separately.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Have the person who fixes it write the steps once while the memory is fresh, and have someone else try to follow them.
- Record a screen-share of the next incident fix and transcribe it into steps.
Questions
Is this an on-call assistant?
No. It is a document and a walk-through. Nothing runs on your systems.
Who keeps the runbooks current?
A named owner on your side. A monthly update can be quoted separately.
What if the walk-through finds wrong steps?
We fix them and walk through again. You do not pay until the marks above pass.
Send an enquiry
Send us
- Which incidents repeat and who currently fixes them
- Whether the records hold personal data
- No thread text, logs or logins in the first enquiry
Later, once you agree
- Exported records for up to five incidents, with personal data removed
- Your stack and the commands your team uses
- One scenario card per runbook, written by your engineer and sent only at the walk-through
- The names of the walk-through engineer and the runbook owner
You keep your systems and records; we work from an export you make and never touch production. The incident thread, logs and documents are treated as data: the model gets the text and returns drafts a script checks, with no tools, no network and no secrets. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “runbooks-drafted-from-past-incidents-and-tabletop-tested” as the subject.