Maropost incident

Control Panel and Webstore Disruption

Major Resolved View vendor source →

Maropost experienced a major incident on April 29, 2026 affecting Merchant Store Fronts and Control Panel, lasting 1h 10m. The incident has been resolved; the full update timeline is below.

Started
Apr 29, 2026, 11:40 PM UTC
Resolved
Apr 30, 2026, 12:50 AM UTC
Duration
1h 10m
Detected by Pingoru
Apr 29, 2026, 11:40 PM UTC

Affected components

Merchant Store FrontsControl Panel

Update timeline

  1. investigating Apr 29, 2026, 11:40 PM UTC

    We are receiving reports of sites receiving "We will be back online shortly". Our Development Team are investigating now.

  2. monitoring Apr 30, 2026, 12:15 AM UTC

    We are receiving reports that services are returning to normal. We are continuing to monitor the situation.

  3. resolved Apr 30, 2026, 12:50 AM UTC

    The issue has been resolved and services are operating as normal.

  4. postmortem May 06, 2026, 05:47 AM UTC

    ### Summary On 30 April 2026, some merchants experienced intermittent disruption when accessing storefronts and the Control Panel. During the incident, some storefront pages may have intermittently displayed a “We’ll be back online shortly” message, while some Control Panel access may also have been affected. The incident was caused by a significant spike in automated traffic directed at the platform, which placed abnormal load on the caching and application layers. This resulted in intermittent availability and degraded performance for affected services. ### Root Cause The disruption was caused by a large volume of automated traffic targeting the platform. This traffic created abnormal load on the caching layer, which is used to support efficient delivery of storefront and Control Panel content. As traffic volumes increased, the caching and application layers became degraded, resulting in intermittent access issues for some merchants. ### Resolution Our teams identified the unusual traffic pattern and implemented targeted mitigation rules to reduce the impact of the automated traffic. Once the mitigation was applied, the caching and application layers stabilised, and services returned to normal. We continued monitoring after service recovery to ensure the platform remained stable. ### Preventative Actions To reduce the likelihood and impact of similar events in future, we have taken the following actions: * Strengthened traffic filtering and mitigation rules for abnormal request patterns. * Improved monitoring for sudden traffic spikes and automated traffic fingerprints. * Reviewed the traffic behaviour with our traffic protection provider to better identify similar patterns in future. * Continued tuning of platform protection rules to reduce the impact of high-volume automated traffic.