Readme 장애 기록

1. 2026년 10월 23일 오후 3:46 UTCinvestigating

   현재 문서 페이지를 로딩할 때 503 오류와 타임아웃을 높이는 문제가 발생했습니다.

2. 2026년 10월 23일 오후 3:46 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 10월 23일 오후 3:47 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

4. 2026년 10월 23일 오후 4:07 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

5. 2026년 10월 23일 오후 4:09 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 10월 14일 오후 10:44 UTCinvestigating

   우리는 현재 왜 페이지가 404를 보여주는 조사하고 있습니다

2. 2026년 10월 14일 오후 10:51 UTCidentified

   우리는 문제점을 확인하고 고침에 일하고 있습니다

3. 2026년 10월 14일 오후 10:52 UTCmonitoring

   수정이 배포되었으며 현재 운영 서버를 배포하고 있습니다. 몇 가지 캐쉬가있을 수 있습니다 404s, 그래서 당신은 여전히 문제로 실행 하는 경우 지원 하십시오

4. 2026년 10월 14일 오후 10:55 UTCresolved

   프로젝트는 다시 표시됩니다. [email protected]으로 연락 주시기 바랍니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 22일 오후 2:22 UTCinvestigating

   우리는 현재 높은 대기 시간 및 대기 응답 시간이 허브에 영향을 미칩니다. 뿌리 원인을 확인하고 정상적인 서비스를 복원하는 Actively 일.

2. 2026년 9월 22일 오후 2:41 UTCmonitoring

   수정이 구현되어 현재 결과를 모니터링하고 있습니다. 성과는 정상에 돌려야 합니다.

3. 2026년 9월 22일 오후 3:03 UTCmonitoring

   우리는 추가 기여 요인을 식별하고 적극적으로 해결하기 위해 노력하고 있습니다.

4. 2026년 9월 22일 오후 3:16 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

5. 2026년 9월 22일 오후 4:44 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 8일 오후 4:04 UTCinvestigating

   우리의 관리 공용영역은 정전을 경험하고 있습니다. ReadMe 개발자 허브를 방문하는 최종 사용자의 능력은 비공개되지 않습니다.

2. 2026년 9월 8일 오후 4:15 UTCinvestigating

   우리는 상황을 해결할 수 있었다. 몇 분 동안 일부 간헐적인 슬러기가있을 수 있습니다.

3. 2026년 9월 8일 오후 4:16 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 21일 오후 4:36 UTCidentified

   현재 고객 허브에 대한 느린 검색 결과를 경험하고 있습니다

2. 2026년 8월 21일 오후 6:21 UTCresolved

   검색 및 성능이 향상되었습니다. 이메일 [email protected] 검색을 통해 여전히 문제가있는 경우

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 24일 오후 12:22 UTCmonitoring

   제3자 인프라 문제로 인해 폭발적인 성능. 우리는 이 상황을 감시하고 우리의 끝에 안정성을 유지하기 위하여 일하고 있습니다.

2. 2026년 7월 24일 오후 1:37 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 6월 17일 오후 3:28 UTCinvestigating

   We are currently investigating an incident related to API Reference pages.

2. 2026년 6월 17일 오후 6:10 UTCresolved

   This incident was resolved and normal site function has been resolved

1. 2026년 5월 28일 오후 1:40 UTCinvestigating

   We're actively investigating this issue.

2. 2026년 5월 28일 오후 1:43 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026년 5월 28일 오후 2:35 UTCidentified

   Systems are getting back up. We're continuing to work on a permanent fix for this issue.

4. 2026년 5월 28일 오후 3:27 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

5. 2026년 5월 28일 오후 3:33 UTCmonitoring

   We are continuing to monitor for any further issues.

6. 2026년 5월 28일 오후 5:53 UTCmonitoring

   We are receiving reports of degraded performance and are actively investigating. We will provide updates as more information becomes available.

7. 2026년 5월 28일 오후 8:04 UTCmonitoring

   Systems appear stable and we are actively rolling out a series of fixes. We will continue to monitor and provide updates

8. 2026년 5월 29일 오전 1:49 UTCmonitoring

   Systems remain stable. Improvements and fixes have been rolled out and we are continuing to monitor.

9. 2026년 5월 29일 오후 5:03 UTCmonitoring

   Systems remain stable, and we are continuing to monitor the situation. Bi-directional sync was on a maintenance job from 9:50 - 11:59 AM (ET) and is now operational.

10. 2026년 5월 29일 오후 6:36 UTCmonitoring

    Systems remain stable and our team continues to deploy targeted fixes. Work is ongoing to address degraded read performance across the system, including serving all 404s from cache. We’ll be actively monitoring over the weekend, and we will provide a full RCA next week.

11. 2026년 6월 1일 오후 6:16 UTCresolved

    Our systems have been stable since Friday, May 29th. We're monitoring closely and improving spike detection to prevent recurrence and adding proactive capacity monitoring to detect admin dashboard degradation before it impacts customers. Full root cause analysis coming soon. Thanks for your patience and understanding.

1. 2026년 5월 27일 오후 1:51 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 5월 27일 오후 2:52 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026년 5월 27일 오후 3:57 UTCmonitoring

   We're slowly recovering and monitoring the situation.

4. 2026년 5월 27일 오후 5:08 UTCmonitoring

   We are monitoring the issue.

5. 2026년 5월 27일 오후 5:17 UTCmonitoring

   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. 2026년 5월 27일 오후 5:43 UTCinvestigating

   We are seeing some slow performance, possibly 500 errors. investigating

7. 2026년 5월 27일 오후 5:47 UTCinvestigating

   We are continuing to investigate this issue.

8. 2026년 5월 27일 오후 6:02 UTCmonitoring

   Performance has improved, but we're still investigating the issue.

9. 2026년 5월 27일 오후 8:54 UTCmonitoring

   Performance and loading is still being affected, and we're in the process of rolling out fixes

10. 2026년 5월 27일 오후 10:37 UTCresolved

    This incident has been resolved.

11. 2026년 6월 3일 오후 3:28 UTCpostmortem

    ### 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 during the incident are permanent. We are continuing to expand cache coverage across additional endpoints and page types. * **Bot and traffic protection:** Strengthening rate limiting and abuse detection to prevent bot traffic from contributing to backend load. * **Monitoring and alerting:** Adding proactive capacity monitoring with earlier thresholds so the team can intervene before customers are affected. * **Incident response:** Improving our internal processes for faster escalation and more frequent status page updates during multi-day incidents. ### Final Note During the incident, we posted an update referencing a platform update. That was our initial hypothesis based on timing. Further investigation confirmed it was unrelated. The change in question was a routine, isolated configuration update and had no impact on the outage or any other customers. We should have waited for confirmation before publishing it, and we're tightening our internal process for status page updates as a result. We know how critical your documentation is to your customers, and this level of disruption is not acceptable. We have already shipped meaningful improvements to prevent recurrence, and the work outlined above will continue through the coming weeks. If you have questions, reach out to your account team or contact [[email protected]](mailto:[email protected]).

1. 2026년 5월 26일 오후 5:41 UTCinvestigating

   We are experiencing slow performance across customer hubs

2. 2026년 5월 26일 오후 5:49 UTCmonitoring

   We have identified and quickly fixed the issue and are currently investigating a more thorough fix

3. 2026년 5월 27일 오전 3:54 UTCresolved

   This incident has been resolved.

1. 2026년 5월 26일 오후 1:39 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 5월 26일 오후 2:26 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2026년 5월 26일 오후 3:37 UTCresolved

   This incident has been resolved.

1. 2026년 5월 12일 오후 2:15 UTCidentified

   We are investigating slowness across hubs.

2. 2026년 5월 12일 오후 7:38 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2026년 5월 12일 오후 9:10 UTCresolved

   This incident has been resolved.

1. 2026년 5월 11일 오후 3:43 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 5월 11일 오후 4:03 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026년 5월 11일 오후 5:08 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026년 5월 11일 오후 6:34 UTCresolved

   This incident has been resolved.

1. 2026년 5월 7일 오후 11:43 UTCinvestigating

   We are currently investigating an issue creating changelogs

2. 2026년 5월 8일 오전 12:40 UTCidentified

   We have identified the issue preventing the changelog creation page from rendering correctly, and we are working on a fix

3. 2026년 5월 8일 오전 3:02 UTCmonitoring

   We have deployed the fix and are monitoring the results

4. 2026년 5월 8일 오전 3:18 UTCresolved

   This incident has been resolved.

1. 2026년 4월 28일 오후 6:38 UTCinvestigating

   We are currently investigating an issue where customers are unable to create branches

2. 2026년 4월 28일 오후 7:02 UTCidentified

   We have identified the issue and are currently looking into a fix

3. 2026년 4월 28일 오후 7:31 UTCresolved

   Branches and versions can now be created successfully

1. 2026년 4월 24일 오후 12:17 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 4월 24일 오후 12:29 UTCinvestigating

   We are continuing to investigate this issue.

3. 2026년 4월 24일 오후 1:42 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026년 4월 24일 오후 3:11 UTCresolved

   This incident has been resolved.

1. 2026년 4월 22일 오후 2:35 UTCinvestigating

   We are currently investigating downtime impacting admin users.

2. 2026년 4월 22일 오후 2:40 UTCidentified

   An issue has been identified with a third-party provider. A fix is being implemented.

3. 2026년 4월 22일 오후 2:53 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026년 4월 22일 오후 2:56 UTCmonitoring

   Admin dashboard is recovering and we are continuing to monitor for further issues.

5. 2026년 4월 22일 오후 2:59 UTCmonitoring

   Fix has been applied and admin requests have recovered. We are continuing to monitor for any further issues.

6. 2026년 4월 22일 오후 4:36 UTCresolved

   Issues with admin requests have been resolved.

1. 2026년 4월 22일 오전 2:59 UTCinvestigating

   We are currently investigating performance issues across the platform.

2. 2026년 4월 22일 오전 3:08 UTCidentified

   We've discovered the issue and have implemented a quick fix

3. 2026년 4월 22일 오전 3:43 UTCresolved

   Fix has been implemented and performance has stabilized.

1. 2026년 4월 20일 오후 8:05 UTCidentified

   The admin interface is experiencing slower than expected response times.

2. 2026년 4월 20일 오후 9:16 UTCmonitoring

   Performance has returned to normal, and we are continuing to monitor.

3. 2026년 4월 20일 오후 9:20 UTCresolved

   This incident has been resolved.

1. 2026년 4월 16일 오후 4:07 UTCinvestigating

   We are getting reports of slow performance and 500 errors when loading pages

2. 2026년 4월 16일 오후 4:57 UTCmonitoring

   We've stabilized our platform and our response times have improved. We are currently monitoring the situation.

3. 2026년 4월 16일 오후 7:25 UTCresolved

   Performance has stabilized and we are no longer returning errors upon loading pages.