asgasgagas

Makeswift's Incident on May 20, 2026

May 20, 2026

Incident Report



On May 20th, 2026, Makeswift experienced a series of API latency spikes between approximately 2:30 a.m. and 10:30 a.m. ET. During this period, Makeswift's API experienced four distinct two-minute spikes in which response times were significantly elevated, causing slow page loads for sites that do not implement caching, with Catalyst being the most notable example. The Makeswift Builder was also affected during these brief spikes.We apologize for the disruption this caused. We know how critical reliable, fast loading speeds are to your business, and we're taking steps to make sure this doesn't happen again.





What happened?



The latency spikes were triggered by a surge of bot traffic hitting a customer's storefront. Because Catalyst passes page view traffic directly to Makeswift's API (with each page load generating 1–15 API requests), the bot traffic flooded our API at a volume it was not designed to handle.Makeswift's API was originally built as a management API. Prior to Catalyst, live page traffic was served exclusively through Vercel's incremental static regeneration, so our API was never exposed to spikes like these. With Catalyst's architecture, that assumption no longer holds.When the traffic volume exceeded what our API could absorb, our database connection pool became saturated, leading to elevated latency and, in some cases, request timeouts.





Incident Response Timeline



All times below are in the Eastern Standard Timezone on May 20th, 2026.



2:20 AM: A series of large traffic spikes began hitting the API from the storefront being affected by the bot.

2:24 AM: Error rates began climbing.

2:28 AM: Internal alerting fired, paging on-call engineers.

2:32 AM: Incident declared.

3:22 AM: Source of the traffic spike identified.

3:44 AM: Determined that the impacted endpoint required rate limiting.

4:32 AM: Rate limiting deployed to production; subsequent spikes had a significantly reduced impact on latency.

4:59 AM: Incident initially declared resolved.

5:30 AM – 5:56 AM: Two additional spikes observed; muted effect due to rate limiting.

10:30 AM: Negative cache deployed, allowing the API to handle high-volume 404 traffic without hitting Redis or the database.

10:40 AM: Final traffic spike observed with no increase in latency detected.



The API was experiencing elevated latency across four two-minute spikes between 2:30 a.m. and 6:00 a.m., and was fully resolved at 10:30 a.m.





Short Term Resolution



  • Deployed rate limiting on the impacted endpoint, significantly reducing the effect of subsequent traffic spikes.
  • Deployed a negative cache to absorb high-volume 404 traffic without hitting Redis or the database, fully eliminating the latency impact of additional spikes.





Long Term Mitigation



  • We are working to ensure Catalyst page view traffic does not pass through to Makeswift's API, so that incidents of this type are significantly less likely.
  • We are building a CDN for Makeswift's API designed to handle high traffic volumes and thundering herds. This project was already on our roadmap for this summer, and this incident underscores its importance.
  • We are improving request tracing to identify the source of traffic spikes faster, reducing time to diagnosis in future incidents.
  • We are auditing our API endpoints for rate limiting gaps and establishing rate limiting as a default requirement for new endpoints going forward.



We sincerely apologize for the impact this had and appreciate your patience. If you have any questions, reach out to us at support@makeswift.com.