Website and Dashboard outage

What to do

• Check whether you use Uploadcare Dashboard, Website. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 2h 48m it lasted.

  Anything that failed between 2026-07-16 08:42 UTC and 2026-07-16 11:30 UTC may need a replay.

• Subscribe to Uploadcare's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=uploadcare works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from Uploadcare 5

1. investigatingJul 16, 2026, 8:42 AM UTC

   We are currently investigating an issue affecting Website and Dashboard. Users may experience an increased number of errors. Our team is working to identify the root cause, and we will provide an update as soon as more information becomes available. We apologize for any inconvenience and appreciate your patience.

   provider

2. identifiedJul 16, 2026, 8:52 AM UTC

   Our team has identified the cause of the issue impacting Website and Dashboard and is actively working to implement a permanent solution. Some users may still experience connectivity issues during this time. We will continue to share updates as we make progress toward full resolution. Thank you for your continued patience.

   provider

3. identifiedJul 16, 2026, 11:11 AM UTC

   Our team is working to implement a permanent solution. Some users may still experience connectivity issues during this time. We will continue to share updates as we make progress toward full resolution.

   provider

4. resolvedJul 16, 2026, 11:30 AM UTC

   The issue affecting Website and Dashboard has been resolved as of 11:30 UTC. Users should no longer experience the issue. Our team is continuing to monitor performance to ensure stability. We apologize for any disruption this issue may have caused and appreciate your understanding. Thank you for your patience, and please reach out to support if you notice anything unusual.

   provider

5. postmortemJul 21, 2026, 10:50 AM UTC

   On July 16, 2026, between 07:55 UTC and 11:15 UTC \(approximately 3 hours and 20 minutes\), Uploadcare’s website and customer portal were partially unavailable. During this window, affected requests could fail at our CloudFront distributions with 504 Gateway Timeout errors and never reached our backend services. The disruption was caused by a global Amazon Web Services \(AWS\) CloudFront outage affecting VPC Origins, the origin type we rely on for website and customer portal. Requests routed through VPC Origins failed, while CloudFront distributions using other origin types were unaffected. AWS later attributed the outage to an internal capacity constraint in the fleet that manages connections to private VPC origins, which caused routing configuration to be distributed incorrectly to its network processors. Importantly, our core platform services — including file uploading, storage, processing, and delivery of already-cached files — were not affected by this incident and continued to operate normally throughout. Our follow-up work focuses on keeping a proven, ready-to-deploy fallback for this class of AWS CloudFront failure. # **Timeline of events** _All times are in UTC on July 16, 2026._ * **07:55 —** CloudFront metrics begin showing elevated error rates for our website and webclient distributions. * **07:59 —** Our monitoring alerts that [uploadcare.com](http://uploadcare.com) is unreachable. Our engineering team begins investigating immediately. * **08:02 —** We confirm 504 errors for [uploadcare.com](http://uploadcare.com) and observe that requests are not reaching our backend. Other our CloudFront distributions remain healthy. * **08:07 —** Based on the error pattern and the CloudFront-generated 504 error page, CloudFront becomes our primary suspected root cause. At this point AWS had not yet posted any notice, though the wider community had begun reporting CloudFront problems. * **08:28 —** We confirm the issue is affecting our public websites and customer portal. * **08:42 —** CloudFront metrics show an error rate of approximately 30%. * **08:44 —** AWS acknowledges a global CloudFront outage related to VPC Origins — approximately 49 minutes after our impact began. * **09:23 —** We begin implementing a fallback: switching affectted origins from VPC Origins to internet-facing Application Load Balancers \(ALBs\). * **10:58 —** The fallback is deployed to our staging environment for validation. * **11:02 —** The fallback passes validation on staging. We begin rolling the same changes toward production. * **11:15 —** AWS resolves the underlying outage. Our production websites and customer portall fully recover and error rates return to zero. Because AWS recovered first, the production fallback was not required. We declare the incident resolved. # **What went well** * **Fast detection and diagnosis.** Our monitoring detected the failure within minutes, and our team correlated it with a broader AWS issue and identified the likely root cause before AWS acknowledged the outage publicly. * **A validated mitigation.** During the incident we designed, implemented, and validated a fallback — switching CloudFront origins from VPC Origins to internet-facing ALBs — on our staging environment. AWS recovered before we needed to apply it to production, but this is now a proven mitigation for future VPC Origins incidents. * **Contained impact.** Because the failure was limited to distributions using VPC Origins, our core platform — file uploads, storage, processing, and cached delivery — remained fully operational. # **What went wrong** * **A shared origin dependency.** Our public website and customer portal distributions all relied on CloudFront VPC Origins, so a single AWS subsystem failure affected them together with no failover. # **Action items** * **Keep a ready-to-deploy CloudFront fallback.** We have prepared and validated infrastructure changes to switch affected distributions from VPC Origins to internet-facing ALBs, so this mitigation can be applied quickly should a similar AWS outage recur. We sincerely apologize for the disruption this incident caused, and for the delay in communicating it through our status page. While the root cause was an AWS-side outage outside our direct control, we are committed to reducing our exposure to this class of failure and to communicating more quickly and transparently in the future.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.