Summary

On August 20, 2026, MyCashflow stores returned intermittent errors for approximately three and a half hours. The cause was an automatic operating system critical security update that was installed on our application servers and turned out to be faulty. The software vendor has already withdrawn the update and published a corrected version by now.

Impact

All MyCashflow stores were affected. The failure was intermittent rather than total: a share of page loads returned an error while others completed normally, and reloading a page often succeeded. Between approximately 09:16 and 09:37 store performance was additionally degraded while traffic was concentrated on a reduced number of servers during the repair.

Outage window: August 20, 2026, 06:07–09:37 EEST.

Root Cause

Our application servers receive operating system critical security updates automatically. The update installed on the morning of August 20 contained a defect in the web server software that caused a portion of requests to fail with an error instead of being served.

The vendor identified this defect and withdrew the update the previous evening, publishing a corrected version. That correction had not yet reached the update source our servers use, so the automation installed the faulty version that was still being offered to them.

Detection

Automated external monitoring alerted us at 06:35, and merchant reports reached our support channels from 06:56 onwards. Failure was intermittent and many requests completed normally, reloading a page often succeeded. This issue was not automatically picked up by our datacenter partner, as servers were serving requests but only with a higher than normal error rate.

Once the engineers with the relevant expertise was engaged at 07:46, the overnight update was identified as the cause shortly afterwards and work began on finding a way to restore services.

Timeline (EEST)

• 06:07 – Automatic security update installed on first server; errors begin on a small share of requests
• 06:35 – First automated monitoring alert
• 06:40 - Automatic security udpate installed on all the servers
• 06:56 – Merchant reports reach our support channels; internal investigation begins
• 07:07 – Datacenter partner contacted
• 07:12 – Public status page updated (Investigating)
• 07:46 – Our engineers engaged to investigate
• 08:05 – Overnight security update identified as the probable cause
• 08:44 – Course of action for restoring service decided; work begins
• 08:51 – Status page updated (Identified)
• 09:37 – Previous working version restored on all application servers; error rates fall
• 09:43 – Status page updated (Monitoring)
• 10:02 – Service confirmed stable; incident closed

Resolution

The faulty update was rolled back on all application servers, returning them to the previously working version. Error rates fell immediately and service returned to normal.

What we’re doing going forward

Software vendors occasionally publish a defective update and later withdraw it, as happened here. What we are changing is how such an update can reach production in the first place. Our servers currently install critical security updates automatically from a source that is continuously updated. We will move back to a manual schedule and plan this in cooperation with our datacenter provider.