Quay.io refused pushes for about fourteen hours and Red Hat gives database scaling as the cause

Sources: primary, discussion
Summary: Red Hat's status page opens the incident at 2026-09-14 13:34 UTC as degraded performance on the Quay.io push and pull API, and the 14:02 and 14:04 UTC updates state Red Hat identified the cause of the image pull failures. Read-only mode, described as only pulls being served, began at 15:35 UTC, and the 2026-09-15 04:05 UTC Monitoring update states the fix has been deployed and Quay.io is serving read/write requests. Red Hat marked the incident Resolved at 2026-09-15 09:15 UTC, states the registry has been operational since 05:00 UTC that day, states the recovery required updating three affected database tables, and gives the cause in its own words as an underlying issue related to database scaling that was resolved successfully without any data loss. The same resolution note states Clair vulnerability scanning remains on maintenance until further notice.
Why it matters: A registry that answers pulls but refuses pushes keeps deployments running while release pipelines stall, so this class of incident surfaces in build jobs well before anything user-facing breaks.
Follow-up: Track whether Red Hat takes Clair vulnerability scanning off maintenance.