Last checked: 18 seconds ago
Get notified about any outages, downtime or incidents for imgix and 1800+ other cloud vendors. Monitor 10 companies, for free.
Outage and incident data over the last 30 days for imgix.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage. It's completely free and takes less than 2 minutes!
Sign Up NowOutlogger tracks the status of these components for Xero:
Component | Status |
---|---|
API Service | Active |
Docs | Active |
Purging | Active |
Rendering Infrastructure | Active |
Sandbox | Active |
Stripe API | Active |
Web Administration Tools | Active |
Content Delivery Network | Active |
Amsterdam (AMS) | Active |
Ashburn (BWI) | Active |
Ashburn (DCA) | Active |
Ashburn (IAD) | Active |
Atlanta (ATL) | Active |
Atlanta (FTY) | Active |
Atlanta (PDK) | Active |
Auckland (AKL) | Active |
Boston (BOS) | Active |
Brisbane (BNE) | Active |
Buenos Aires (EZE) | Active |
Cape Town (CPT) | Active |
Chennai (MAA) | Active |
Chicago (CHI) | Active |
Chicago (MDW) | Active |
Chicago (ORD) | Active |
Columbus (CMH) | Active |
Content Delivery Network | Active |
Copenhagen (CPH) | Active |
Curitiba (CWB) | Active |
Dallas (DAL) | Active |
Dallas (DFW) | Active |
Denver (DEN) | Active |
Dubai (FJR) | Active |
Frankfurt (FRA) | Active |
Frankfurt (HHN) | Active |
Helsinki (HEL) | Active |
Hong Kong (HKG) | Active |
Houston (IAH) | Active |
Johannesburg (JNB) | Active |
London (LCY) | Active |
London (LHR) | Active |
Los Angeles (BUR) | Active |
Los Angeles (LAX) | Active |
Madrid (MAD) | Active |
Melbourne (MEL) | Active |
Miami (MIA) | Active |
Milan (MXP) | Active |
Minneapolis (MSP) | Active |
Montreal (YUL) | Active |
Mumbai (BOM) | Active |
Newark (EWR) | Active |
New York (JFK) | Active |
New York (LGA) | Active |
Osaka (ITM) | Active |
Palo Alto (PAO) | Active |
Paris (CDG) | Active |
Perth (PER) | Active |
Rio de Janeiro (GIG) | Active |
San Jose (SJC) | Active |
Santiago (SCL) | Active |
Sāo Paulo (GRU) | Active |
Seattle (SEA) | Active |
Singapore (SIN) | Active |
Stockholm (BMA) | Active |
Sydney (SYD) | Active |
Tokyo (HND) | Active |
Tokyo (NRT) | Active |
Tokyo (TYO) | Active |
Toronto (YYZ) | Active |
Vancouver (YVR) | Active |
Wellington (WLG) | Active |
DNS | Active |
imgix DNS Network | Active |
NS1 Global DNS Network | Active |
Docs | Active |
Netlify Content Distribution Network | Active |
Netlify Origin Servers | Active |
Storage Backends | Active |
Google Cloud Storage | Active |
s3-ap-northeast-1 | Active |
s3-ap-northeast-2 | Active |
s3-ap-southeast-1 | Active |
s3-ap-southeast-2 | Active |
s3-ca-central-1 | Active |
s3-eu-central-1 | Active |
s3-eu-west-1 | Active |
s3-eu-west-2 | Active |
s3-eu-west-3 | Active |
s3-sa-east-1 | Active |
s3-us-east-2 | Active |
s3-us-standard | Active |
s3-us-west-1 | Active |
s3-us-west-2 | Active |
View the latest incidents for imgix and check for official updates:
Description: # What happened? On June 08, 2021, between the hours of 09:58 UTC and 10:36 UTC, our CDN provider experienced a [global CDN disruption](https://status.fastly.com/incidents/vpk0ssybt3bj) that severely impacted the imgix service. At 10:36 UTC, our CDN provider applied a fix that allowed us to begin restoring service, and we began processing a large backlog of render requests that had accumulated from the start of the outage. Our CDN provider marked their incident as resolved at 12:41 UTC. Our engineers later identified an issue affecting <1% of image requests to the service and applied a fix at 20:22 UTC. The incident was marked fully resolved by 21:26 UTC although most images were being successfully served by 12:41. # How were customers impacted? Between 09:58 UTC and 10:50 UTC, a significant percentage of requests to the imgix service returned an error. The CDN provider outage prevented logs from being sent from the CDN to imgix so imgix customers will not have analytics for this time period. After the CDN outage was marked as resolved by our provider \(12:41 UTC\), approximately 94% of all requests to imgix resulting in a successful response. This number gradually increased over the course of several hours. By 17:14 UTC, 99% of all requests resulted in a successful response, and the service was mostly restored. Due to an issue affecting a small number of images, the service was not marked as fully resolved until 21:19 UTC. # What went wrong during the incident? This outage was unprecedented in a few ways: * Our CDN provider experienced a major outage that lasted longer than any incident we have previously experienced with them. * A large volume of rendering traffic queued up during the longer-than-average downtime. * The CDN provider outage also caused a large number of previously rendered derivatives to be removed from cache, which when combined with the render backlog, contributed to our systems seeing sustained loads up to 4x our typical peak traffic levels. By 10:36 UTC a fix was applied which restored the CDN service. However, the sheer volume of incoming rendering traffic combined with the increased origin load from a much lower-than-normal cache-hit ratio prevented our service from completing an immediate recovery. By 11:00 UTC, traffic was being served with an 89% success rate. Several recovery strategies were implemented to handle the fallout caused by the initial outage: * We repurposed rendering capacity from other environments to process the dramatic surge of render requests * Our engineers tuned the rendering stack to handle a much higher load than normal * Tapered load shedding was implemented to reduce stress on the network As mitigations were implemented, the service reached a > 99% delivery success rate by 17:14 UTC. By this time, our status page should have been updated. Due to a smaller issue affecting a small portion of renders, we did not consider the incident fully resolved until 20:22 UTC, which was when all errors had returned to normal levels. # What will imgix do to prevent this in the future? We will be evaluating possible fallbacks in the case of total CDN failure, along with investigating our caching capacities to prevent events of a similar scale from having such an impact on our rendering services in the future. Projects are already underway to dramatically increase render capacity under sustained loads as well as unexpected spikes. At the same time, we will be working closely with our CDN partner to discuss their own remediation steps and how we can best interact with them moving forward. We will also be revisiting our processes to ensure that status updates are more frequent, as the majority of the service was restored far sooner than we indicated on our status page.
Status: Postmortem
Impact: Critical | Started At: June 8, 2021, 10:12 a.m.
Description: # What happened? On June 08, 2021, between the hours of 09:58 UTC and 10:36 UTC, our CDN provider experienced a [global CDN disruption](https://status.fastly.com/incidents/vpk0ssybt3bj) that severely impacted the imgix service. At 10:36 UTC, our CDN provider applied a fix that allowed us to begin restoring service, and we began processing a large backlog of render requests that had accumulated from the start of the outage. Our CDN provider marked their incident as resolved at 12:41 UTC. Our engineers later identified an issue affecting <1% of image requests to the service and applied a fix at 20:22 UTC. The incident was marked fully resolved by 21:26 UTC although most images were being successfully served by 12:41. # How were customers impacted? Between 09:58 UTC and 10:50 UTC, a significant percentage of requests to the imgix service returned an error. The CDN provider outage prevented logs from being sent from the CDN to imgix so imgix customers will not have analytics for this time period. After the CDN outage was marked as resolved by our provider \(12:41 UTC\), approximately 94% of all requests to imgix resulting in a successful response. This number gradually increased over the course of several hours. By 17:14 UTC, 99% of all requests resulted in a successful response, and the service was mostly restored. Due to an issue affecting a small number of images, the service was not marked as fully resolved until 21:19 UTC. # What went wrong during the incident? This outage was unprecedented in a few ways: * Our CDN provider experienced a major outage that lasted longer than any incident we have previously experienced with them. * A large volume of rendering traffic queued up during the longer-than-average downtime. * The CDN provider outage also caused a large number of previously rendered derivatives to be removed from cache, which when combined with the render backlog, contributed to our systems seeing sustained loads up to 4x our typical peak traffic levels. By 10:36 UTC a fix was applied which restored the CDN service. However, the sheer volume of incoming rendering traffic combined with the increased origin load from a much lower-than-normal cache-hit ratio prevented our service from completing an immediate recovery. By 11:00 UTC, traffic was being served with an 89% success rate. Several recovery strategies were implemented to handle the fallout caused by the initial outage: * We repurposed rendering capacity from other environments to process the dramatic surge of render requests * Our engineers tuned the rendering stack to handle a much higher load than normal * Tapered load shedding was implemented to reduce stress on the network As mitigations were implemented, the service reached a > 99% delivery success rate by 17:14 UTC. By this time, our status page should have been updated. Due to a smaller issue affecting a small portion of renders, we did not consider the incident fully resolved until 20:22 UTC, which was when all errors had returned to normal levels. # What will imgix do to prevent this in the future? We will be evaluating possible fallbacks in the case of total CDN failure, along with investigating our caching capacities to prevent events of a similar scale from having such an impact on our rendering services in the future. Projects are already underway to dramatically increase render capacity under sustained loads as well as unexpected spikes. At the same time, we will be working closely with our CDN partner to discuss their own remediation steps and how we can best interact with them moving forward. We will also be revisiting our processes to ensure that status updates are more frequent, as the majority of the service was restored far sooner than we indicated on our status page.
Status: Postmortem
Impact: Critical | Started At: June 8, 2021, 10:12 a.m.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage or down time. Join for free - no credit card required.