[{"data":1,"prerenderedAt":102},["ShallowReactive",2],{"article-real-time-dashboard-problem":3},{"id":4,"title":5,"accentColor":6,"body":7,"category":14,"coreIdea":15,"crossLink":18,"ctaBody":24,"ctaLinkText":25,"ctaLinkTo":26,"datePublished":27,"description":11,"extension":28,"headline":29,"headlineAccent":30,"heroParagraph":31,"meta":32,"navigation":33,"ogDescription":34,"ogTitle":35,"path":36,"publishedAt":37,"readTime":38,"sections":39,"seo":74,"seoDescription":75,"seoTitle":76,"sidebarLink":77,"stem":80,"summaryCards":81,"tags":97,"teaser":100,"__hash__":101},"articles\u002Farticles\u002Freal-time-dashboard-problem.md","Real Time Dashboard Problem","blue",{"type":8,"value":9,"toc":10},"minimark",[],{"title":11,"searchDepth":12,"depth":12,"links":13},"",2,[],"Data platforms",{"heading":16,"body":17},"A dashboard can feel fast and still be too stale for the decision.","The question is not whether the dashboard refreshes often. The question is what happens when someone acts on data that is already old.",{"accentColor":6,"label":19,"title":20,"description":21,"linkText":22,"linkTo":23},"Real-world example","A genuinely real-time data platform — built in production.","Live agricultural commodity pricing, WebSocket feeds, and charting that holds up under load for a South African market data provider.","Read case study","\u002Finsights\u002Fcase-studies\u002Fsa-market-data-charting-platform","SSS builds data platforms and dashboards for South African businesses, including genuinely real-time systems where the use case demands it. We scope the data requirements before we design the architecture.","Talk about your data problem","\u002Fcontact","2026-03-01","md","The hidden problems with real-time dashboards","and why most of them aren't actually real-time.","'Real-time' is one of the most overloaded terms in software. The gap between what it means in a marketing context and what it means in a technical context causes real problems for businesses that depend on live data to make decisions.",{},true,"'Real-time' is one of the most overloaded terms in software. The gap between the claim and the technical reality causes real problems for businesses that depend on live data.","Real Time Dashboard Performance — What 'live' actually means","\u002Farticles\u002Freal-time-dashboard-problem","March 2026","8 min read",[40,46,55,64],{"id":41,"navLabel":42,"paragraphs":43},"intro","The claim",[44,45],"\"Real-time\" is one of the most overloaded terms in software. The gap between what it means in a marketing context and what it means in a technical context causes real problems for businesses that depend on live data to make decisions.","\"Real-time\" often means \"faster than the thing you had before\", which isn't the same as actually live. When a vendor says their dashboard is \"real-time,\" they might mean the data refreshes every 30 seconds. Or every minute. Or that it updates live, but only after a human uploads a file.",{"id":47,"navLabel":48,"pillLabel":49,"pillColor":6,"heading":50,"paragraphs":51},"meaning","What real-time means","What real-time actually means","Real-time is event driven, not just frequent refreshes.",[52,53,54],"A genuinely real-time system is one where data changes on the client are driven by events on the server, not by the client periodically asking \"has anything changed?\" The technical implementation is usually WebSockets or Server-Sent Events: a persistent connection where the server pushes updates as they happen, rather than waiting to be asked.","Polling, where the client asks the server for new data every N seconds, is not real-time. It's close to real-time, depending on the polling interval, but there's always a delay between when something happens and when the dashboard shows it. For commodity trading, or live dispatch management, or any system where decisions need to be made on current information, that gap matters.","The problem is that polling looks like real-time to most users, right up until it doesn't. When the polling interval is 30 seconds and you make a decision based on data that's 28 seconds old, the consequences aren't always obvious until something goes wrong.",{"id":56,"navLabel":57,"pillLabel":58,"pillColor":59,"heading":60,"paragraphs":61},"why","Why most are not live","Why most dashboards aren't actually live","teal","Polling is easier. Real-time takes more engineering.",[62,63],"Building a genuinely real-time system is harder than building one that polls. WebSocket connections need to be managed. They disconnect, they need to handle reconnection, they need to maintain state across connection drops. The backend needs a pub\u002Fsub architecture to broadcast updates to multiple clients efficiently. Under load, the connection management becomes a significant engineering concern.","Polling is simpler. It works. For a lot of use cases, it's good enough. The problem is when businesses are sold on \"real-time\" dashboards that are actually polling every minute, and only discover the gap when they're making decisions that depend on the data being current.",{"id":65,"navLabel":66,"pillLabel":67,"pillColor":68,"heading":69,"paragraphs":70},"matters","When it matters","When it actually matters","lime","The architecture should match the cost of stale data.",[71,72,73],"The honest answer is that real-time isn't always necessary. For most reporting use cases, weekly sales figures, monthly P&L, end-of-day operations summaries, a dashboard that refreshes every few minutes is perfectly adequate. The data doesn't need to be live because the decisions aren't live.","But for commodity pricing, live dispatch visibility, active trading, or any system where a decision made on stale data has a real cost, genuine real-time matters. The question to ask isn't \"is this dashboard fast?\" It's \"what's the cost of making a decision on data that's 30 seconds old?\"","If the answer is \"nothing significant,\" polling is fine. If the answer is \"we could lose a trade, miss a dispatch, or make a wrong call\", then the architecture needs to be built for the actual requirement, not the easier implementation.",{"description":11},"Real time dashboard performance depends on architecture, not marketing claims. Most dashboards sold as 'real-time' aren't. Here's how to tell the difference and why it matters.","Real Time Dashboard Performance — What 'live' actually means | Sharp Software Solutions",{"text":78,"to":79},"View data platforms","\u002Fservices\u002Fdata-platforms","articles\u002Freal-time-dashboard-problem",[82,87,92],{"label":83,"value":84,"body":85,"icon":86,"accentColor":6},"Polling","Close, not live","The dashboard asks for updates every few seconds or minutes. There is always a delay.","i-lucide-refresh-cw",{"label":88,"value":89,"body":90,"icon":91,"accentColor":59},"WebSockets","Event driven","The server pushes updates to the client as the data changes.","i-lucide-radio-tower",{"label":93,"value":94,"body":95,"icon":96,"accentColor":68},"The question","What does stale data cost?","If 30 seconds changes the decision, the architecture needs to be truly live.","i-lucide-timer",[98,99,88,14],"Real-time","Dashboards","'Real-time' is one of the most overloaded terms in software. The gap between the marketing claim and the technical reality causes real problems for businesses that depend on live data to make decisions.","6BSBfg9rOp5wN177Brh5kQJ554xlosrz7x1HSQUMuXA",1778227874060]