When a WordPress problem is recovered, you may want to end your work by saying, “I’m glad the site is back.”However, if you do not record what happened, why it was discovered late, and what actions were helpful, the same problem may repeat in the next update.
What is needed is not a remorseful letter blaming someone for their failures.This is a review of failures that arranges facts in chronological order, finds weak points in systems and procedures, and works with the person in charge to make improvements with a deadline.
In this article, we will explain how to easily create a recurrence prevention report even at a small inn while using Codex and Claude Code to help organize records.
- Conclusion: Write a report that covers not only “events” but also “next actions”
- Which obstacles to look back on?
- When should you do a review?
- Separate facts, guesses, and judgments
- Impact that you want to record due to accommodation problems
- “Cause” is not necessarily one
- Review work left to AI
- Divide the improvement measures into three types
- How to write good improvement items
- Request text to AI that can be used with copy and paste
- Report template
- Return improvements to operation
- Check if the improvement is complete
- Checklist for the host
- Information used for reference
- Summary
Conclusion: Write a report that covers not only “events” but also “next actions”
At least the following six things remain.
- What happened?
- What impact has it had on people seeking accommodation, existing reservations, and operations?
- What did you do from discovery to recovery?
- What are the direct causes and factors that spread the damage?
- What responses were successful and what were you unsure about?
- Who will improve what and by when?
If you end it with “Be careful next time,” you can go back to it when things get busy. Add a person in charge, a deadline, and completion conditions to each improvement plan.
Which obstacles to look back on?
No need for long reports for every small display shift. It is worth keeping a short record if you have any of the following:
- The official website did not open for a certain period of time.
- Some reservations, inquiries, and payments could not be used.
- Incorrect price/closed/resident cat information was displayed
- Data was lost or duplicated
- Restored from backup and rewound version
- Urgent response from server and production companies was required.
- We first noticed this through customer contact, not through monitoring.
- Repeated same type of problem
- Suspected impact on personal information and accounts
If we suspect personal information leakage or unauthorized access, we do not simply review the matter in the usual way; we also consult with our contractors, experts, and the necessary related organizations. We do not conclude that there is no leakage before checking.
When should you do a review?
The site has just opened and we are still checking for recovery. Check reservations, inquiries, emails, prices, and smartphone displays, and look back after things have calmed down.
As a guide, it is divided into the following two stages.
Today: Save the facts
- Time of occurrence/discovery/contact/recovery
- Screen, short errors, monitoring results
- Changes made and by whom
- Information for customers
- Backups and versions used
- unconfirmed matters
Within a few days: Discuss cause and improvement
- Direct cause
- Factors behind delay in discovery and recovery
- Useful mechanism
- Recurrence prevention measures
- Person in charge, deadline, completion conditions
As time passes, memories of “Maybe it was like this” become mixed in. I’ll just leave the time and facts early.
Separate facts, guesses, and judgments
AI can naturally connect sentences even when information is lacking. Therefore, the contents of the report are clearly divided.
| Category | Example |
|---|---|
| Fact | After the update operation, the specific URL responded with 500 |
| Speculation | The updated plugin may have been involved |
| Judgment | We chose to stop additional updates and revert to the previous version |
| unconfirmed | Impact on inquiry emails has not been confirmed |
“There was a plugin name in the error log” and “that plugin was the root cause” are two different things. If there is no verification result to support it, write candidate cause or unconfirmed.
Impact that you want to record due to accommodation problems
Reports for engineers tend to focus only on server downtime, but for hotels, the impact on business is important.
Impact on customers
- Time when the official website could not be viewed
- Time when the reservation button was not available
- Possibility of viewing incorrect price, vacancy, or closing information
- Possibility that the inquiry could not be sent
- Delay in notification to existing reservation holders
Impact on inn operations
- Number of cases accepted by phone or OTA instead
- Whether or not there are duplicate reservations or call-back confirmations.
- Time spent by staff responding
- Urgent request to production company/maintenance company
- Updates that may have been lost due to restore
If you do not know the number, do not make a guess and record it as “Unable to confirm.”
“Cause” is not necessarily one
In addition to the cause of the failure, there are factors that make discovery and recovery difficult.
Direct cause
- Compatibility with original CSS broke due to theme update
- A fatal error occurred when updating the plugin.
- Insufficient storage space
- The reservation URL was incorrect after changing the settings.
Contributing factors
- Updated multiple items at the same time
- The screen before the update was not saved.
- There was no verification environment
- Did not try backup restore procedure
- The reservation page was not included in the monitoring target.
- The scope of responsibility of the server company and production company was unclear.
- There was no change record and the previous work could not be identified.
If one person’s attentiveness is the only cause, another person will fail in the same situation. Think about why the operation seemed safe and why the mechanism couldn’t be stopped.
Review work left to AI
Codex and Claude Code can help organize:
- Create a time series table from notes and log times
- Classify facts, speculation, and unconfirmed
- Summary of versions and file differences before and after update
- Organize sales impact by item
- Rephrase the contributing factors as “systems” instead of “people”
- Categorize improvement plans into prevention, detection, and recovery
- Point out improvement items that lack the person in charge and deadline
- Separate documents for internal use and external explanations
- Create plans for additions to operational procedures and AI instructions
However, we will not let the AI fill in the facts that it does not know. Leave the time, cause, and number of impacts that are not in the conversation record or log as “unconfirmed.”
Divide the improvement measures into three types
1. Prevent
- Update one item at a time
- Try first in the verification environment
- Back up before changes and keep the screen
- Do not edit the parent theme directly
- Limit AI execution privileges
2. Discover early
- Monitor not only the top page but also the reservation/inquiry URL
- Check the screen differences between your computer and smartphone
- Automatically check the updated HTTP, description, and image
- Check the reception status of administrator email
3. Return quickly
- Prepare alternative reservation routes
- Clarify maintenance personnel and contact information
- Experiment with backup integrity and restore
- Record the steps to revert to the previous version
- Temporary information template for customers
If you make too many improvement plans for a single problem, they will not be implemented. Compare the effect on sales and the amount of work, and narrow it down to one to three options.
How to write good improvement items
| Vague improvements | Possible improvements |
|---|---|
| Pay attention to updates | Create a pre-update checklist and use it from the next update |
| Check the backup | Perform a restore test in an isolated environment and record the results |
| Strengthen monitoring | Add HTTP confirmation on reservation page and set contact information in case of abnormality |
| Use AI safely | Updates, deletions, and restarts must be approved and added to the instructions |
Add the following to each item.
- Person in charge
- Deadline
- Completion conditions
- Person to confirm
- Related procedures
Completion conditions should not be “considered” but should be in a form that can be confirmed, such as “procedures have been created and tried once.”
Request text to AI that can be used with copy and paste
Create a time series
Please create a time series table after recovery from the following WordPress failure memo.
[Memo with date and time, changes made, screen recording]
Please divide it into occurrence, discovery, contact, temporary response, cause investigation, recovery, and confirmation.
Do not fill in dates or events that are not recorded, and mark unknown dates as "unconfirmed."
Do not include personal information, credentials, or internal passes in your report.
Sort out causes and contributing factors
From the following confirmed facts, sort out the direct causes, contributing factors, and unconfirmed matters.
[Verification results, update history, error summary]
Avoid expressions that place blame on individuals, and organize from the perspectives of procedures, authority, monitoring, information, and the environment.
Please do not conclude the cause without evidence.
Change to improvement item
Review the following failures and create measures to prevent recurrence.
[Review summary]
Categorize into prevention, early detection, and early recovery and go to each item.
Please include priority, person in charge, deadline, completion conditions, and confirmation method.
First, narrow down the items you want to implement to three or less and explain why.
Please do not change the site or server yet.
Reflect in AI operation rules
Please make a proposal to add the safety rules obtained from this failure to AGENTS.md or CLAUDE.md.
Check to see if there is any overlap with existing rules, including regular work, prior approval, prohibited items,
Please show me where to put it in the confirmation items.
Do not include connection information, internal paths, actual commands, or customer information.
Please do not change the file yet and only present the difference proposal.
Report template
# Name of the incident
## Overview
- Date of occurrence:
- Recovery confirmation:
- Features affected:
- Sales impact:
## Time series
- Time / Confirmed facts / Action taken / Person in charge
## Cause
- Confirmed direct causes:
- Contributing factors:
- unconfirmed matters:
## Compatible
- What worked:
- Things that need improvement:
## Recurrence prevention
- Improvement items / Priority / Responsibility / Deadline / Completion conditions
## Related materials
- Secure references to instructions, screen recordings, and official documentation
Customer names, reservation details, email addresses, IP addresses, passwords, private keys, management screen URLs, etc. will be excluded or managed separately depending on the scope of sharing. When introducing a failure case as a public article, we also exclude internal configuration and information that can be used for attacks.
Return improvements to operation
Just writing a report will not prevent it from happening again. Return the improvements to the place where they will actually be used.
- Monthly inspection checklist
- WordPress update procedure
- Backup and restore instructions
- Disability response card
- Server company/maintenance company contact information
AGENTS.mdfor CodexCLAUDE.mdfor Claude Code- Automatic confirmation of playwright etc.
How to record discussions with AI in operational rules is also explained in How to record discussions with AI in operational manual.
Check if the improvement is complete
It is not enough to just look at whether the deadline has passed a month later.
- Did you use the checklist in the actual update?
- Were you able to restore the backup to another environment?
- Can monitoring detect the intended abnormality?
- Can the staff provide alternative reservation information?
- Can you find contact information even if the person in charge is not available?
- Will the AI suggest or execute prohibited operations without approval?
If possible, perform a small training exercise in a secure testing environment. Do not intentionally stop your production site to try it out.
Checklist for the host
- [ ] After confirming recovery, the facts with date and time were saved.
- [ ] Sorted out the impact on customers and the inn’s operations.
- [ ] Separated into fact, speculation, judgment, and unconfirmed
- [ ] Separate direct causes and contributing factors
- [ ] We reviewed the system and procedures without blaming individuals.
- [ ] Proposed improvement plans for prevention, early detection, and early recovery.
- [ ] Narrowed down the initial improvements to three or less.
- [ ] With person in charge, deadline, and completion conditions
- [ ] Reflected in AI operation rules and procedure manual
- [ ] I later checked to see if the improvements were actually used.
For information on what to do immediately after a failure, please refer to The first 30 minutes after a WordPress failure, for investigating the cause, please refer to Isolating themes, plugins, and caches, and for recovery preparations, please refer to Restoration rehearsal with AI.
Information used for reference
- Google SRE: Postmortem culture of learning from failure
- Google SRE Workbook: Postmortem Practice
- WordPress official: Version control
- WordPress official: Backup
Summary
The purpose of failure review is not to find people who have failed. The idea is to maintain the confirmed facts and effects and change the system to one that allows work to be done safely under the same conditions.
AI can speed up the formatting of time series, classification of facts and speculation, suggestions for improvements, and report generation. The host determines sales impact, priorities, assignees, deadlines, and completion conditions. If you can improve even one aspect of your operations after recovery, you can turn failure handling into knowledge that will lead to peace of mind in the future, rather than just a loss.
