Building a real-time dashboard with SignalR and C#

Real-time dashboards have moved from luxury to necessity across Australian enterprises. Sydney fintechs monitor live mortgage approvals, Brisbane logistics providers track long-haul trucks crossing the NSW-Queensland border, and energy traders follow the Australian National Electricity Market in seconds. The shift from batch reports to live visualisations reflects an expectation that data should arrive at the speed of decision making, whether you are watching an assembly line in Melbourne or bushfire alerts for a regional council.

SignalR sits in a comfortable spot for .NET developers who need bidirectional communication between servers and browsers without hand-rolling WebSocket upgrades. The library negotiates transport automatically, falls back gracefully when older browsers drop the protocol, and integrates with dependency injection the way an ASP.NET Core developer expects. For teams already running C# in production, adopting SignalR feels more like extending an existing skill set than learning a parallel stack, particularly when the deadline is driven by end-of-financial-year reporting.

This walkthrough assumes you are comfortable with C# 10 or later on a working ASP.NET Core 8 project. We will look at hub design, client subscriptions, scaling out across Australian data centres, and the usability touches that turn a wall of blinking numbers into something a shift supervisor actually trusts. The aim is a dashboard that updates in well under one second and degrades politely when bandwidth gets patchy, whether the user is in a Perth CBD office or tethered through regional mobile coverage in the Pilbara.

Comparing real-time transport options

For an Australian compliance officer comparing transport overhead during a network audit, these columns usually justify SignalR. Raw WebSockets and gRPC need careful proxy traversal, which becomes painful when frontline workers use devices locked down by corporate policy and tunnelled through Melbourne-headquartered security stacks. SSE is fine for one-way price tickers but cannot push commands back, ruling out the click-to-refresh interactions finance teams often request.

Long polling still earns a place when the network path is hostile, for instance inside a steel mill where the plant firewall blocks anything fancier than repeated GETs. Pick the row that matches your network realities rather than the row that matches your enthusiasm. The remainder of this article assumes SignalR, but the patterns translate well elsewhere.

Designing hubs and DTO contracts

SignalR hubs are not much more than RPC endpoints, but the contracts you define quietly shape the client experience. Use strongly typed hubs with Task-returning methods so client code gets IntelliSense in Visual Studio and stack traces stay readable. Keep the payload small, ship a version number on every message, and agree on a timestamp format. DateTimeOffset serialised in ISO 8601 is the safe default because it survives trips through nodes hosted across AEST, ACST and AWST without off-by-one-hour bugs.

For multi-tenant dashboards, group features become your best friend. A mine in Kalgoorlie only wants its shift's conveyor-belt metrics, while a Melbourne retailer wants store-level granularity. Clients.Group(tenantId).SendAsync(...) keeps traffic scoped without resorting to per-connection routing logic. Combine that with a publishing service that fans updates out from a background queue, and you have a hub that stays responsive even when the upstream ERP system is having a rough morning.

Schema evolution is the unglamorous discipline that pays off two years later. Once you commit a hub method to production, you cannot remove a property without flagging warnings in rolling deployments. Add new fields, never rename existing ones, and ship a small payload diff rather than the full state on every tick. The high-throughput Cosmos DB review walks through partitioning strategies that pair well with this pattern, which is why the combination shows up across Sydney financial services teams.

Rendering speed on the client side

A dashboard that updates twenty times per second is useless if the chart library freezes the main thread while redrawing. Stick to canvas-based renderers, or use libraries such as Chart.js with animation: false, and opt for incremental updates over full repaints. Keep the state of each tile in a small store, perhaps a Redux slice or a simple BehaviorSubject in an Angular project, and let only the affected cells repaint. Watching a Sydney trading floor demo where the lag between event and screen is below two hundred milliseconds reminds you why those small investments in rendering hygiene matter.

Avoid fetching data twice. The hub should be the single source of truth, and the initial state load should be served through a normal REST or GraphQL endpoint that the hub later enhances. This split also helps with the Notifiable Data Breaches scheme, because the bulk personal data in the initial snapshot tends to be the only piece the regulator wants tagged and audited. All incremental updates flowing through the hub are anonymised counts and aggregates, which keeps the privacy footprint narrow.

Accessibility matters even on speed-critical dashboards. Provide a button that announces the latest value through the screen reader, respect prefers-reduced-motion, and keep contrast ratios high enough for the Australian sun pouring through a north-facing window in a Parramatta office. A bored operator who cannot read the screen will eventually stop trusting it, and that is a worse outcome than a CPU spike.

Scaling out with the Azure backplane

A single ASP.NET Core process can comfortably host a few hundred concurrent hub connections, which is plenty for a regional rollout but not enough for an ASX-listed company during end-of-day reporting. The recommended pattern is to add the Azure SignalR Service as a managed backplane so each app server speaks to a central relay instead of gossiping state between nodes. Reconnection storms become the backplane's problem, not yours, which is a quiet relief at three in the morning.

The handshake between ASP.NET Core and the Azure relay is straightforward. Configure the connection string, replace the in-process AddSignalR() call with AddSignalR().AddAzureSignalR(), and verify that the negotiation endpoint returns the relay URL. From there, attach Application Insights to surface slow fan-outs and use Azure Monitor to alert when the connection count breaches thresholds that matter for your licensing tier. Tie alerts into the on-call roster for your operations team, including the after-hours escalation list for the Sydney NOC if you host in Australia East.

SignalR does not own the data, it just pushes it, leaving you free to choose a store that matches your read patterns. The Cosmos DB change feed pattern complements SignalR nicely for any team publishing updates from an event-sourced pipeline rather than polling a SQL view. The pairing is becoming a default recipe in financial services across Sydney and Melbourne under APRA's CPS 234 regime that expects an immutable audit trail of operational risk decisions.

Observability, throttling and the human side

Both silent and runaway dashboards deserve their own monitoring views. Wire your hub to OpenTelemetry, emit metrics for inbound messages, outbound messages, average client latency, and reconnection rate, then ship those numbers to whatever observability tool your team already runs. Datadog, New Relic and Application Insights all consume SignalR telemetry through OTel exporters with minimal custom code, which means the SRE rotation in Brisbane gets the same view they have for the rest of the stack.

Throttling is where SignalR shows its maturity. Configure client timeouts generously, but enforce server-side rate limits per connection so a runaway loop on the client cannot drain CPU on the hub. ConcurrentMessageLimit and manual SemaphoreSlim checks around expensive hub methods keep a single bad client from degrading the experience for everyone else on the same app instance. The pattern feels heavy until you see the first rogue browser tab in a regional call centre lock up the floor manager's display, and you remember why you wrote it.

User-facing throttling matters too. When the upstream system slows down, do not just stop pushing updates. Push a "stale" indicator so the operator knows the number on screen has not been refreshed for fifteen seconds. That small visual cue is the difference between a confident decision and a confusing one, and it is far easier to defend in a post-incident review under the Privacy Act 1988 than a screen that quietly shows yesterday's totals. The Office of the Australian Information Commissioner tends to be less bothered by visible staleness than by invisible deception.

Deployment patterns and rollout playbook

Hosting inside Australian data centres is non-negotiable for many of the workflows we have discussed. Both Azure Australia East and Azure Australia Southeast regions offer the SignalR Service, and most enterprises standardise on Australia Central for regulated workloads because of its compliance certifications. Pin your deployments there, store container artefacts in the matching ACR, and document the data sovereignty story in your security pack, particularly if you handle health data covered by the My Health Records Act.

For AWS or GCP teams, the managed equivalents (API Gateway WebSocket APIs, Firebase Realtime Database) work but require a small adapter layer because the connection lifecycle does not match SignalR's. On-prem deployments remain common in mining and defence, where a single hub running on a hardened Windows Server box is often more reliable than a satellite link from a Pilbara camp. Schedule heavy rebuilds for the Sunday evening window, push client updates through a service worker so users pick them up between shifts, and treat the hub as a stateful service with rolling restart and drain time.

A few practical habits carry the project across the finish line, especially when the team is distributed across Sydney, Melbourne and the regions.

• Start with a single screen and a tightly bounded scope, then expand once the network is trusted.
• Negotiate the SignalR transport in development with throttled bandwidth to expose hidden latency assumptions.
• Back every hub method with an integration test that connects, sends, and asserts within a strict timeout.
• Pin the dashboard to Australian data centre regions and document the data residency position in plain English.
• Treat stale data as a first-class state on the screen, not as an afterthought in the bug tracker.