Account location error

Update timeline

1. identified Aug 18, 2026, 12:12 PM UTC

   Account information based on a location are returning no results, this includes canteen pages.

2. resolved Aug 18, 2026, 12:12 PM UTC

   This incident has been resolved.

3. postmortem Aug 18, 2026, 12:34 PM UTC

   **Incident report: Account location errors, 18 August 2026** Between approximately 12:08 and 12:24 BST today, some customers were unable to place Cloud Canteen orders or load parts of their account and reporting pages. We are sorry. Ordering lunch should be one of the least eventful things in your day and for sixteen minutes it was not. If your team missed an ordering window because of this, we would like to hear from you so we can put it right. **What happened** Between approximately 12:08 and 12:24 BST today, some customers were unable to place Cloud Canteen orders or load parts of their account and reporting pages. We are sorry. Ordering lunch should be one of the least eventful things in your day and for sixteen minutes it was not. If your team missed an ordering window because of this, we would like to hear from you so we can put it right. **What happened** We release updates to the Feedr platform continuously and in stages, so that changes can be verified before they reach everyone. During one of those releases this morning, part of the platform received an update while another part it depends on had not yet finished being updated. The two halves briefly disagreed about how to read account and location information, which caused errors on any page or action that needed it. **What this meant for you** For the duration of the incident, and depending on which part of the product you were using, you may have seen: * Errors when opening Cloud Canteen or attempting to place an order * Account and location details failing to load * Dashboard and reporting pages returning an error rather than data No orders were lost, no payments were taken incorrectly and no customer data was exposed or altered. Anything that failed, failed cleanly rather than being partially saved. Orders placed successfully before and after the incident were unaffected. **Timeline** | Time \(BST\) | Event | | --- | --- | | 12:08 | Elevated errors detected and our status page was updated | | 12:11 | Cause identified as a mismatch introduced during a staged release | | 12:19 | Corrective change applied | | 12:24 | Error rates returned to normal and the incident was resolved | **What we are doing about it** We resolved this in sixteen minutes, but it should not have reached customers at all. Our focus is on how this release was managed rather than on recovering faster next time. **Changing how releases of this kind are managed.** Updates that span dependent parts of the platform will be co-ordinated and sequenced deliberately, with the release owned end to end by an engineer rather than left to complete on its own. Where a release does not complete as expected, it will be stopped and put back to a known good state before anything further proceeds. **Watching more closely around releases.** We are tightening the monitoring we watch during and immediately after a release, so that the signals we already collect are being actively reviewed at the point of highest risk rather than relied on to raise an alarm after the fact. **Reviewing this incident properly.** Our engineering team is going through this incident in full this week. Anything that comes out of that review which changes how we release will be adopted, and we will update this report if there is more to tell you. **If this affected you** If your organisation missed an ordering deadline or you have any concern about an order placed around this time, please contact your Feedr account manager or our support team and we will investigate individually. Thank you for your patience. We would rather tell you plainly what went wrong than not mention it at all.