Incident Report: Image Cropping Producing Distorted Results in Publish
Date: 9th April 2026 Duration: 2h 10m Severity: Minor
Summary Customers using the image cropping feature in Publish received visually distorted (stretched) results instead of properly cropped images. The issue affected all combinations of source and target aspect ratios, with no workaround available to customers during the incident window. The team identified the cause, deployed a revert, and confirmed cropping was working correctly again before closing the incident.
Root Cause The incident was caused by a regression introduced in a recent code change to how image URLs are constructed for our image CDN. The change added logic to ensure a dimension-changing operation was always present in image URLs, which is a requirement of the CDN when applying effects like brightness or contrast.
However, the detection logic did not recognize the "crop" operation as a dimension-changing operation. When a customer applied a crop, the system mistakenly appended a resize back to the original image dimensions. The CDN then performed the crop first and stretched the result back to the original dimensions, producing the distorted output.
Customer Impact Any customer who used the image cropping feature in Publish during the incident window received a visually stretched result. The issue affected square, landscape, and portrait images alike, with no combination of input or target aspect ratio unaffected. Three customer reports were received through our support channels before the issue was resolved.
Steps to Resolution After the team was paged, the on-call lead first verified that the underlying image processing infrastructure was healthy, ruling out a CDN or pod-level issue. The investigation then focused on a recent code change related to image URL handling that had been merged a few hours before the first customer report. The team confirmed the timing alignment, identified the precise gap in the URL operation detection logic, and prepared a revert. Once the revert was deployed and verified in production, our support team replied to the affected customers asking them to hard refresh their browsers, which restored normal cropping behavior. A follow-up fix was later re-applied with comprehensive test coverage to prevent the original issue from recurring.
Key Learnings
The original change shipped without test coverage for crop interactions, which allowed the gap in operation detection to slip through review. The follow-up fix included thirteen test cases covering crop-only flows, crop combined with effects, and various offset formats. We're treating this as the standard of coverage that should accompany changes to image URL construction going forward.
Detection relied on customer reports rather than proactive monitoring. We're exploring automated visual regression tests and client-side checks for unexpected URL patterns (such as a resize operation appearing directly after a crop) that would surface this kind of issue before customers notice.
