Is Feedr down?

We are investigating an issue affecting Checkout & card payment, Catering orders service and Catering ordering & quotes. You may see errors or missing information on these parts of Feedr. We are working on it and will update this page as we learn more.

All affected services have returned to normal. A full incident report follows.

We are investigating an issue affecting Vendors service, Vendor portal, Website & marketplace and Catering ordering & quotes. You may see errors or missing information on these parts of Feedr. We are working on it and will update this page as we learn more.

All affected services have returned to normal. A full incident report follows.

**Incident report: reduced performance, 27 August 2026** Between approximately 05:49 and 05:59 BST, parts of Feedr were slower than usual and some pages did not load correctly. We are sorry. Ordering lunch should be one of the least eventful things in your day, and for a few minutes it was not. **What happened** Early that morning, demand on the systems that serve supplier and menu information rose sharply, to roughly double what we would expect at that time of day. While those systems scaled to meet the increase, requests took longer to process than normal, and some did not complete within the time our services allow before giving up. That is why some pages were slow, showed incomplete information or returned an error instead of loading. Demand returned to normal within a few minutes and performance recovered on its own, without any intervention needed. Nothing was lost, altered or left in a broken state at any point. Two characteristics of our current setup meant the spike was felt more than it should have been. The database serving this information does not yet have a second copy to share read traffic across, and one of our services opens a new database connection for each request rather than drawing from a shared pool. Both are scaling characteristics rather than faults, and both are now under review. **What this meant for you** For the duration, and depending on which part of the product you were using, you may have seen slower page loads, incomplete supplier or menu information or an error where a page would normally appear: * Website & marketplace * Catering ordering & quotes * Supplier information * Vendor portal A small number of individual requests did not complete and would have shown an error at the time. Trying again would have worked normally once performance recovered. Sign-in, checkout and card payments were unaffected and remained available throughout. No data was lost, altered or exposed. **Timeline** | Time | Event | | --- | --- | | 05:45 BST | Demand on the affected systems began rising above normal levels | | 05:49 BST | Some requests began taking longer than our services allow and returned errors | | 05:54 BST | Our monitoring detected the problem and opened this incident | | 05:57 BST | We updated this page to confirm we were investigating | | 05:59 BST | Demand had returned to normal, performance had recovered and the incident was closed | **What we are doing about it** Everything recovered on its own within a few minutes, but we would rather it had not reached you at all. * We are adding monitoring of database load directly, covering both connection volume and processing capacity, so we can see demand building before it affects anyone. In this case the pressure was visible several minutes before any page was affected. * We are investigating our scaling requirements for these systems as demand grows, including adding a second database copy to share read traffic and pooling connections for the service that opens them individually. * We are widening what our monitoring covers, so that more of the ordering journey and more of the regions we operate in are checked continuously rather than inferred from the services behind them. We will continue to monitor demand patterns and review capacity ahead of growth rather than in response to it. **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.

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

This incident has been resolved.

**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.