> ## Content Index > Fetch the complete content index at: https://blog.tsd.digital/llms.txt > Use this file to discover other available public pages before exploring further. # Why did our orders stop when every system said it was running fine? - URL: https://blog.tsd.digital/why-did-our-orders-stop-when-every-system-said-it-was-running-fine/ - Published: 2026-10-19T07:00:00.000Z - Updated: 2026-10-19T07:00:00.000Z - Description: Orders stopped but every system looked fine? Your site likely waited on a live ERP or supplier lookup. Fetch prices on a schedule and store them locally. - Author: Tim Gaunt - Tags: QuestionsWeAsk, 200k Mid Market Ecommerce, Ecommerce, Advice Your website was probably working as designed. It made add-to-basket wait on another system, usually the ERP or a supplier's, never built to serve a website. When that went quiet, there was no price, so nobody could buy. The fix is to fetch prices and stock on a schedule, store them locally and agree how long they stay valid. The video, transcript and FAQs for this first episode of our questions series are on the [episode page](https://tsd.digital/questions/1?ref=blog.tsd.digital). This is the longer version, for anyone who has stared at a wall of green dashboards while the order count sat at zero. ## Orders stop while every dashboard stays green Someone in sales spots it first, usually mid-afternoon, when the order notifications dry up. Hosting says the site is up and the payment provider has nothing to report. The ERP is ticking along with its own jobs. Customers, meanwhile, are looking at product pages where the price never loads. Some click add-to-basket and get a spinner. Most of them don't ring to complain. They leave. One business we were asked to look at priced every basket line by asking the ERP at the moment the customer clicked. On the afternoon in question, a month-end reporting job had slowed the ERP to a crawl. Nothing crashed. Each lookup took twenty-odd seconds, the website gave up after fifteen, and add-to-basket failed quietly until someone noticed the takings. Every monitor stayed green, as each system was fine by its own measure. Nobody blamed the system at the far end. The customer had never heard of it, and as far as they could tell, the website broke. ![](https://storage.ghost.io/c/64/5b/645b11c2-b436-444c-a523-58dca4ca7bd8/content/images/2026/10/SchedulesWorkingAndNot.png) ## Why live lookups sound sensible, and how they fail On paper the reasoning holds up. The ERP holds the true price, including whatever contract terms your trade customers have negotiated, and it knows what's in the warehouse right now. Ask it directly and you get one source of truth with no syncing to manage. If you dropship, your supplier's feed may be the only place your stock levels exist at all. The bad days are where it unravels. A shopper opens a product page, the website asks the ERP for a price and waits. When the answer is quick, nobody notices the dependency. When nothing arrives before the website's timeout, there's no price to show, add-to-basket disappears or throws an error, and the shopper goes elsewhere. An outright failure at least turns something red somewhere. Slow is worse. Each waiting request holds a connection open on your web server, and once hundreds of shoppers are queued behind the same sluggish system, pages that never touch the ERP start dragging too. Partial outages hide even better. Prices come back for some products and some customer accounts, fail for the rest, and the site looks perfectly healthy to whoever checks it from the office. ![](https://storage.ghost.io/c/64/5b/645b11c2-b436-444c-a523-58dca4ca7bd8/content/images/2026/10/SlowPriceNoBasket.png) Most ERPs were designed for a few dozen people in finance and the warehouse, working through screens at human speed. A website can put a thousand shoppers in front of one at once. Picture a category page of 24 products, each firing its own price request, and a modest traffic spike turns into tens of thousands of lookups in a few minutes. Cloud ERPs often cap this deliberately with API rate limits, and from the website's side a throttled request is hard to tell apart from a slow one. ![](https://storage.ghost.io/c/64/5b/645b11c2-b436-444c-a523-58dca4ca7bd8/content/images/2026/10/WebsiteTrafficBottleneckToERP.png) ## Your supplier's SLA does not protect your checkout Put a supplier's feed or a hosted ERP in the path of every basket and their service level becomes yours. A 99.5% availability commitment sounds reassuring until you work out that it allows roughly three and a half hours of downtime a month, and there's no rule saying those hours avoid your busiest trading day. Most SLAs measure availability, and a system that takes twenty seconds to reply still counts as available. It can sit comfortably within its contract while your checkout is effectively shut. Where service credits exist, they tend to be a share of the fee you pay that supplier, which bears no relation to the orders you lost. Your logo is on the page. The lost orders and the dented goodwill land with you. ## Fetch on a schedule and store the data locally The fix is unglamorous. Pull prices and stock from the ERP or supplier on a schedule, store them in the website's own database, and have the business agree how long each kind of data stays valid. Product pages and baskets read from the local copy, which answers in milliseconds whatever the ERP is up to. Finance or the commercial owner should set those windows, since each one is a commercial call. Stock on fast movers might need refreshing every few minutes, while a list price can usually sit for a day. Then decide what happens once data passes its window. For most catalogues we'd show the last-known price and check it against the ERP when the order is placed, which keeps you trading and catches the rare change. Back-orders on uncertain stock, confirmed afterwards, help too if fulfilment can cope. Hiding add-to-basket until fresh data arrives is the cautious route, and you'll pay for it in lost sales. If you're on the IT side, wrap every call to an external system in a circuit breaker. It counts failures and slow responses, and once they pass a threshold it stops sending requests for a set period and fails fast. Your web servers stop queueing on a system that's already struggling, which gives that system room to recover. After the pause a trial request goes through, and normal traffic resumes if it succeeds. Pair it with a cached fallback. While the circuit is open, or whenever a live call fails, the website serves the last good value from its local store and flags it as possibly stale. With the scheduled fetch underneath, any live call you keep is an optional refinement, and an ERP outage becomes a job for the integration team while customers carry on ordering. ![](https://storage.ghost.io/c/64/5b/645b11c2-b436-444c-a523-58dca4ca7bd8/content/images/2026/10/ERP-Pricing-Flow-to-order-2.png) ## The trade-off is some freshness Storing data locally means the price on screen can be slightly out of date. For most catalogues that's an easy trade. Prices tend to move weekly or monthly, and a check at order confirmation catches the odd mismatch before anything is invoiced. Fast-moving prices are a different conversation. Businesses selling metals, fuel or components priced against volatile markets can see meaningful movement within a day. We'd still store locally there, just with the window shrunk to minutes and a firm price check at the point of order. A short window is a far safer bet than a live call that can take the whole checkout down with it. ## How to check your own exposure List every external call your website makes while a customer views a product, then do the same for checkout. Your agency or development team should be able to produce this within a day, and if they can't, that tells you something too. The ERP calls will be obvious. Address lookup and tax calculation are the sort that get forgotten. For each call, find out what the page does if the call fails outright, and what it does if the call takes ten seconds to answer. It's the ten-second answer that catches people out. Most teams have planned for failure. Far fewer have tested slow. Wherever the honest answer is "the customer can't buy", you've found a dependency worth fixing, and ranking them by the revenue flowing through each page tells you where to start. ## Questions to ask your agency or platform provider You don't need to read code to ask these: - If our ERP stopped answering for an hour, could customers still add to basket and check out? - Where do the prices on our product pages come from at the moment the page loads? - How old can a price or stock figure be before we stop showing it, and who decided that? - What happens on screen when a supplier's feed is slow, and what changes when it's down completely? - How would we find out about any of this before our customers did? Good answers are specific and a little boring. Be wary of anyone who tells you it couldn't happen. Every external system has bad days, the well-run ones included. ## Where we ask this first These questions are part of [e-commerce Discovery](https://tsd.digital/discovery?ref=blog.tsd.digital) at TSD, the stage before we build anything, where we map every system your website depends on and agree with you what should happen when each one goes quiet. If your orders have stopped while the dashboards stayed green, or you suspect they could, Discovery is where we'd start. [Get in touch today](https://tsd.digital/discovery?ref=blog.tsd.digital) to see how we can help.