API Reference Degradation
This incident was resolved and normal site function has been resolved
Home
/
Status
/
Service
API documentation for developers to succeed.
Source
auto
Category
Development
Adapter
STATUSPAGE IO
Verified
Pending review
Current state
Operational
Checked 2h ago
12
Components
0
Active incidents
0
Maintenance
5.56%
90d uptime
API Reference Degradation
Jun 17, 3:28 PM
Component changes, incidents, and maintenance windows grouped by day.
operational
degraded
outage
maintenance
unknown
Showing 1 to 12 of 12 tracked components.
| Component | Status | Type | Last changed |
|---|---|---|---|
Upstream Providers | Operational | Group | Not recorded |
ReadMe Hubs All documentation sites hosted on ReadMe's platform | Operational | Component | Not recorded |
ReadMe Knowledge Base The documentation site for the ReadMe platform | Operational | Component | Not recorded |
Admin Dashboard The administrative dashboard used for editing and configuring a ReadMe documentation site | Operational | Component | Not recorded |
Cloudflare CDN/Cache Handles caching for our hubs. View the status details at cloudflarestatus.com | Operational | Component | Not recorded |
Cloudflare SSL for SaaS Provisioning Handles SSL certificate generation when connecting a custom domain to ReadMe. View the status details at cloudflarestatus.com | Operational | Component | Not recorded |
Developer Metrics API metrics provided to ReadMe through the ReadMe API are experiencing delays in processing. Existing metrics are not impacted, and newly added metrics will be queued until the processing delay is resolved. | Operational | Component | Not recorded |
Auth0 User Authentication | Operational | Component | Not recorded |
Owlbot AI ReadMe's AI-powered chatbot | Operational | Component | Not recorded |
Auth0 Machine to Machine Authentication | Operational | Component | Not recorded |
ReadMe Micro | Operational | Component | Not recorded |
Auth0 Management API | Operational | Component | Not recorded |
Follow outages, degraded components, and maintenance updates in your Uptimus workspace with email, push, and webhook alerts.
Related status pages based on category, adapter type, and operational history.
Readme is currently marked as Operational in Uptimus based on the latest official status page check.
Supported status page providers are checked continuously by our scraper scheduler. The public page is cached briefly for SEO and performance.
No. Uptimus stores incidents and maintenance windows separately when the upstream provider exposes enough detail.
Yes. Create an Uptimus workspace, follow this provider, and choose email, push, or webhook notifications.
Normalized official status-page data for incidents, maintenance, components, and history.
5.56%
Known uptime
18 known history days
12
Components tracked
0 outage, 0 degraded
51
Incidents indexed
0 active right now
22
Maintenance windows
0 active or scheduled
Components with the most recent status-page events.
Admin Dashboard
Operational
Auth0 Machine to Machine Authentication
Operational
Auth0 Management API
Operational
Auth0 User Authentication
Operational
Cloudflare CDN/Cache
Operational
1
operational days
0
degraded days
16
outage days
1
maintenance days
72
unknown days
Latest outages and degradations detected from the official status page.
This incident was resolved and normal site function has been resolved
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.
### 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 [support@readme.io](mailto:support@readme.io).
This incident has been resolved.
This incident has been resolved.
This incident has been resolved.
This incident has been resolved.
This incident has been resolved.
Branches and versions can now be created successfully
This incident has been resolved.
Scheduled and completed maintenance windows are separated from incidents.
Maintenance has completed.
The scheduled maintenance has been completed.
The migration is now complete. If you have trouble accessing any parts of the ReadMe knowledge base, please contact us at support@readme.io 🦉
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
Uptimus tracks the official Readme status page, normalizes upstream events, and separates incidents from scheduled maintenance.
Official source
https://www.readmestatus.com
Adapter
STATUSPAGE IO
Alert streams
Incidents, component changes, and maintenance windows.
Public SEO page
Indexable status history for users searching outage information.
Regional reports can be layered on top of official provider status when user signals are available.
Official provider components
Incident and maintenance separation
Workspace alerts and webhooks