Critical incident

ReadMe: ReadMe Refactored Outage

Affected: ReadMe Hubs, ReadMe Knowledge Base, Admin Dashboard

Current status of ReadMe: Operational — live ReadMe status

Timeline

1. May 27, 2026, 13:51 UTC
   investigating
   We are currently investigating this issue.
2. May 27, 2026, 14:52 UTC
   identified
   The issue has been identified and a fix is being implemented.
3. May 27, 2026, 15:57 UTC
   monitoring
   We're slowly recovering and monitoring the situation.
4. May 27, 2026, 17:08 UTC
   monitoring
   We are monitoring the issue.
5. May 27, 2026, 17:17 UTC
   monitoring
   Updated 6/3: A routine configuration update coincided with the downtime window, which led us to initially identify it as the cause. Further investigation confirmed the two were unrelated. See the postmortem for full details.
6. May 27, 2026, 17:43 UTC
   investigating
   We are seeing some slow performance, possibly 500 errors. investigating
7. May 27, 2026, 17:47 UTC
   investigating
   We are continuing to investigate this issue.
8. May 27, 2026, 18:02 UTC
   monitoring
   Performance has improved, but we're still investigating the issue.
9. May 27, 2026, 20:54 UTC
   monitoring
   Performance and loading is still being affected, and we're in the process of rolling out fixes
10. May 27, 2026, 22:37 UTC
    resolved
    This incident has been resolved.
11. Jun 3, 2026, 15:28 UTC
    postmortem
    ### What Happened Beginning Tuesday, May 26, 2026, customers were experiencing slow loading and 503 errors across ReadMe-hosted docs and the admin dashboard. The outage was intermittent but recurring, with the worst periods hitting during business hours when traffic spiked. ### Root Cause An internal data backup process was generating excessive I/O on our storage layer. Under normal traffic conditions, this additional load was manageable. But when it coincided with peak customer traffic and elevated bot activity, total I/O demand exceeded system capacity, causing cascading request timeouts. The maintenance process ran on a recurring schedule, which is why the degradation followed a predictable pattern of spikes throughout each day. Separately, a surge in bot traffic to non-existent pages \(404s\) amplified the problem because those requests were not being served from cache. ### Resolution **Immediate fix:** We identified and disabled the maintenance process causing the excess I/O load. Within three hours, storage utilization returned to normal levels and remained stable. **Additional improvements shipped during the incident:** * Expanded caching across multiple layers, significantly reducing load on backend storage * Hardened 404 handling to serve error pages from cache instead of hitting the backend * Implemented rate limiting and IP-based protections against abusive bot traffic * Optimized several high-traffic API endpoints to reduce redundant backend calls * Added new monitoring and alerting for storage I/O thresholds ### Timeline May 26 - June 1, 2026 | Time | Status | Details | | --- | --- | --- | | Mon 5/26, 6:39 AM PDT | Investigating | Issue reported | | Mon 5/26, 7:26 AM PDT | Monitoring | Fix implemented, monitoring results | | Mon 5/26, 8:37 AM PDT | Resolved | Admin hub incident resolved | | Mon 5/26, 10:41 AM PDT | Investigating | Slow performance across customer hubs | | Mon 5/26, 10:49 AM PDT | Monitoring | Quick fix applied, investigating thorough fix | | Mon 5/26, 8:54 PM PDT | Resolved | Customer hub incident resolved | | Tue 5/27, 6:51 AM PDT | Investigating | Issue reported | | Tue 5/27, 7:52 AM PDT | Identified | Fix in progress | | Tue 5/27, 8:57 AM PDT | Monitoring | Slowly recovering | | Tue 5/27, 10:17 AM PDT | Update | Updated 6/3: A routine configuration update coincided with the downtime window, which led us to initially identify it as the cause. Further investigation confirmed the two were unrelated. See root cause and resolution above. | | Tue 5/27, 1:54 PM PDT | Update | Performance and loading still affected, rolling out fixes | | Tue 5/27, 3:37 PM PDT | Resolved | Incident resolved | | Wed 5/28, 6:40 AM PDT | Investigating | Issue reported | | Wed 5/28, 6:43 AM PDT | Identified | Fix being implemented | | Wed 5/28, 7:35 AM PDT | Update | Systems coming back up, working on permanent fix | | Wed 5/28, 8:27 AM PDT | Monitoring | Fix implemented, monitoring results | | Wed 5/28, 10:53 AM PDT | Update | Reports of degraded performance, actively investigating | | Wed 5/28, 1:04 PM PDT | Update | Systems appear stable, rolling out fixes | | Wed 5/28, 6:49 PM PDT | Monitoring | Improvements and fixes deployed, continuing to monitor | | Thu 5/29, 10:03 AM PDT | Monitoring | Systems stable. Bi-directional sync maintenance 9:50–11:59 AM ET. | | Thu 5/29, 11:36 AM PDT | Monitoring | Deploying targeted fixes. Serving all 404s from cache. Degraded read performance. | | Fri 5/30 | Monitoring | Monitoring continues | | Sat 5/31 | Monitoring | Weekend monitoring | | Mon 6/1, 11:16 AM PDT | Resolved | Root cause identified and resolved. Systems stable since Thursday, May 29. | ### Path Forward We are using this incident to make lasting improvements to reliability and incident response: * **Storage capacity and isolation:** Restructuring how background processes interact with production storage to eliminate contention under load. * **Caching and performance:** The caching improvements shipped durin

Updates as published by ReadMe (original).