https://approjects-vendor-status-watch.static.hf.space/v/fasterize.htmlIncidents from Fasterize's public status page, polled daily.Wed, 16 Sep 2026 12:28:20 +0000https://stspg.io/pw4b7j0mjt8yfasterize:2026-05-22T11:33:50.733+02:00Fri, 22 May 2026 09:33:50 +0000Incident is closed since 11:30am but we keep on monitoring as the incident on our hosting provider is not fully resolved.https://stspg.io/k4vxcg467wvjfasterize:2026-05-20T12:33:55.003+02:00Wed, 20 May 2026 10:33:55 +0000This incident has been resolved.https://stspg.io/c59lbj7cwl6dfasterize:2026-05-20T10:00:37.917+02:00Wed, 20 May 2026 08:00:37 +0000The issue affecting flush operations through the API and dashboard has been fixed. Flush actions are now working normally again.https://stspg.io/nhb0t1gvwn5tfasterize:2026-04-10T22:30:00.000+02:00Fri, 10 Apr 2026 20:30:00 +0000We experienced some issues with our European infrastructure. Service has been restored since 00:20. This has affected loading speeds. Some pages or websites have experienced slowdowns.https://stspg.io/d84bvfj0q5ljfasterize:2026-02-05T13:00:00.000+01:00Thu, 05 Feb 2026 12:00:00 +0000We have identified an issue affecting the accuracy of INP data collected between Thursday, 5 February and Monday, 9 February. During this period, INP metrics were incorrectly reported for Safari on iPhone when the navigation type was back-forward cache (BFCache). This behaviour is related to a known issue in WebKit, which causes inflated INP values in this specific scenario. More details are available in the related Safari bug report: https://bugs.webkit.org/show_bug.cgi?id=305251 The issue has been identified and mitigated on our side. Only the INP metric is impacted; other performance metrics remain unaffected. We apologise for any confusion this may have caused and recommend caution when analysing INP data for Safari iPhone traffic over this time window. If you have any questions, ohttps://stspg.io/8fcv4k703z7jfasterize:2025-11-24T15:50:11.072+01:00Mon, 24 Nov 2025 14:50:11 +0000The incident has been resolved, everything is now operating normallyhttps://stspg.io/rwnp4gsddztkfasterize:2025-10-09T11:01:04.847+02:00Thu, 09 Oct 2025 09:01:04 +0000An in-memory database cluster failure occurred leading to service unavailability across multiple Fasterize components — primarily the **Optimisation Engine** and the **API**. At **09:48**, an in-memory database cluster failure happens after restarting multiple nodes to release a new engine version. The database cluster began an automatic failover sequence, but each time a new node was promoted as primary, it **crashed under excessive connection load**. This cluster serves as a **cache layer** providing access to configurations. During the outage, Engine instances attempted to reconnect at a very high frequency and fell back to retrieving data directly from the main database.This fallback mechanism worked as intended until **10:32**, allowing our optimization engine to continue operating https://stspg.io/ykp8qw9r2kvmfasterize:2025-09-25T10:00:00.000+02:00Thu, 25 Sep 2025 08:00:00 +0000A network maintenance caused a regression in the service responsible for extracting the True-Client-IP header from the X-Forwarded-For header. Around 6% of the platform trafic has been impacted. The issue has now been resolved. We apologize for the inconvenience.https://stspg.io/rm3clrb23s0jfasterize:2025-09-09T15:11:52.763+02:00Tue, 09 Sep 2025 13:11:52 +0000This incident has been resolved.https://stspg.io/g6v10g7j96n8fasterize:2025-09-09T12:13:56.657+02:00Tue, 09 Sep 2025 10:13:56 +0000# **🛠️ Incident Description** **On Tuesday, September 9th, 2025, Fasterize carried out a scheduled maintenance to modernize part of its private network infrastructure.** **During this operation, an unexpected configuration issue temporarily disrupted communication between some components of the platform. This resulted in an increased error rate on part of the traffic between 11:43 and 11:50 \(Paris time\).** # **📅 Timeline** * **11:40 – Update started on the first batch of machines** * **11:43 – Anomaly detected in communication between proxies and fronts** * **11:50 – Issue mitigated, service returned to normal** # **✅ Immediate Actions** * **Affected machines were taken out of rotation** * **Healthy machines were reactivated to absorb the traffic** * **Service stabilized https://stspg.io/f8h3815tsw8sfasterize:2025-09-09T02:30:00.000+02:00Tue, 09 Sep 2025 00:30:00 +0000## **🛠️ Incident Report** **Date:** Tuesday, September 9, 2025 **Duration:** 14:50 – 18:30 \(Paris time\) **Impact:** ~23% of traffic ### **📌 Summary** On September 9, Fasterize performed a planned network maintenance to replace an obsolete private network. As part of this operation, a new private IP address was introduced for our load balancers while keeping the existing ones in place. Later that afternoon, a DDoS attack led to the saturation and restart of one of the load balancers. Following this restart, the load balancer started using the new private IP address to communicate with the backend servers. Since this IP had not yet been registered as a trusted proxy, some requests were processed incorrectly. ### **📈 Impact** * ~23% of traffic was affected between **14:50 and 18:30*