I'm experiencing severe issues with the TMDB image service too. Approximately 75-85% of all image requests from my application are failing with 502 Bad Gateway and 504 Gateway Timeout errors.
Key details about the issue:
Error codes: Consistently receiving 502 and 504 errors
Frequency: Only 15-25% of images load successfully
Consistency: The problem persists across different browsers, devices, and networks
Testing: I've conducted testing through different domains, networks, and even via VPN from different countries with similar results
Implementation: My application uses standard image URLs as per TMDB documentation with lazy loading implemented
This issue affects all types of images (posters, backdrops, profiles) and has been consistent over the past [6 hours]. I've verified that my API implementation is correct as all other API endpoints are functioning normally.
I've attached screenshots showing the console errors and a log of failed requests for your reference.
Could you please investigate this issue with your image CDN or backend servers? This is severely impacting the UX.
Yup, our image backends are having some issues keeping up with the load right now. They're slowly coming back to life and we're seeing signs of improvement over the past hour. Rest assured, we're continuing to monitor them.
I've noticed that images (e.g., posters, backdrops) now download as WEBP rather than JPEG in Chrome. Can I check if it's a deliberate change or perhaps an unintended impact of fixing the issue above?
Hi @rubylane, yes, this is an intended change, we support webp images now.
They're downloading that way because Chrome sends a header saying webp is supported, and is the preferred image format. To force Chrome to download a certain file type, you will probably have to use an extension, something like this Save Image As Type extension. Chrome is generally optimized for performance which is why webp is preferred over jpeg.
If you are having an issue, please create a new thread in the relevant forum. This thread is related to an image outage we had on April 1 which has been fixed.
If you are having an issue, please create a new thread in the relevant forum. This thread is related to an image outage we had on April 1 which has been fixed.
Hello, the same problem with the broken covers started happening again. Thank you very much!
Help!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
Hello, the same problem with the broken covers started happening again. Thank you very much!
defluophoenix 的回复
于 2025 年 04 月 01 日 9:15下午
yes, been happening for the past hour. Hopefully it will get fixed soon
snowtauren 的回复
于 2025 年 04 月 01 日 9:19下午
Yup, happening for me as well, for some strange about 10% images still load correctly.
EHayes 的回复
于 2025 年 04 月 01 日 9:21下午
glad its not only me; all imagers returning 502 on this side
csf.tv 的回复
于 2025 年 04 月 01 日 10:35下午
I’m seeing many broken images as well
Alan_8898 的回复
于 2025 年 04 月 01 日 10:40下午
The API returns broken images; they've been displaying incorrectly for a few days now. I hope themoviedb.com fixes this quickly. Best regards!
blacksnake669 的回复
于 2025 年 04 月 01 日 10:46下午
OK, confirmed on TMDB - the image server is experiencing issues today. TMDB is aware but no idea what the ETA is for bringing it back up.
ivanimprv 的回复
于 2025 年 04 月 01 日 11:40下午
I'm experiencing severe issues with the TMDB image service too. Approximately 75-85% of all image requests from my application are failing with 502 Bad Gateway and 504 Gateway Timeout errors. Key details about the issue:
Error codes: Consistently receiving 502 and 504 errors Frequency: Only 15-25% of images load successfully Consistency: The problem persists across different browsers, devices, and networks Testing: I've conducted testing through different domains, networks, and even via VPN from different countries with similar results Implementation: My application uses standard image URLs as per TMDB documentation with lazy loading implemented
This issue affects all types of images (posters, backdrops, profiles) and has been consistent over the past [6 hours]. I've verified that my API implementation is correct as all other API endpoints are functioning normally. I've attached screenshots showing the console errors and a log of failed requests for your reference. Could you please investigate this issue with your image CDN or backend servers? This is severely impacting the UX.
Travis Bell 的回复
于 2025 年 04 月 02 日 12:05上午
Yup, our image backends are having some issues keeping up with the load right now. They're slowly coming back to life and we're seeing signs of improvement over the past hour. Rest assured, we're continuing to monitor them.
Ruby 的回复
于 2025 年 04 月 03 日 6:08上午
I've noticed that images (e.g., posters, backdrops) now download as WEBP rather than JPEG in Chrome. Can I check if it's a deliberate change or perhaps an unintended impact of fixing the issue above?
Travis Bell 的回复
于 2025 年 04 月 03 日 10:52上午
Hi @rubylane, yes, this is an intended change, we support webp images now.
They're downloading that way because Chrome sends a header saying webp is supported, and is the preferred image format. To force Chrome to download a certain file type, you will probably have to use an extension, something like this Save Image As Type extension. Chrome is generally optimized for performance which is why webp is preferred over jpeg.
Ruby 的回复
于 2025 年 04 月 03 日 11:07上午
Thank you, Travis, for confirming!
Travis Bell 的回复
于 2025 年 04 月 05 日 4:49下午
@WSoliman No, there is no known issue.
If you are having an issue, please create a new thread in the relevant forum. This thread is related to an image outage we had on April 1 which has been fixed.
Alan_8898 的回复
于 2025 年 04 月 18 日 3:32下午
Hello, the same problem with the broken covers started happening again. Thank you very much!
Alan_8898 的回复
于 2025 年 04 月 18 日 3:32下午
Hello, the same problem with the broken covers started happening again. Thank you very much!
Alan_8898 的回复
于 2025 年 04 月 18 日 3:33下午
Help!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 Hello, the same problem with the broken covers started happening again. Thank you very much!