Azure SignalR Service
Does ZopNight manage Azure SignalR Service?
Azure SignalR Service bills per unit per day, with each Standard unit reserved around the clock regardless of connection count. Capacity sized for peak concurrency keeps billing at 3 a.m. ZopNight records SKU and unit counts via Resource Graph and reads 60 days of connection metrics to surface unit rightsizing.
Rules that fire on Azure SignalR Service
No active rule family targets Azure SignalR Service today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Azure SignalR Service manages real-time WebSocket messaging for web applications, billed per unit per day. Standard units provisioned for peak concurrency keep billing at 3 a.m.
Units reserved by the day, not the connection
A SignalR unit is a block of concurrent-connection capacity billed per unit per day. The daily meter runs whether the unit carries its full complement of connections or sits empty overnight, and the unit count only changes when someone changes it. Capacity chosen for launch-day concurrency continues billing on every quiet day that follows. Sizing for the busiest hour therefore means paying for that hour 24 times a day.
Connection-count evidence over 60 days
Discovered via Azure Resource Graph with SKU and unit counts. Azure Monitor metrics across a 60-day lookback show connection counts, Cost Management billing attributes spend, and unit rightsizing surfaces in review. SignalR is not schedulable in ZopNight: real-time messaging capacity cannot be switched off nightly without dropping every connected client, so the savings path is matching units to observed concurrency rather than turning the service off and on.
Peak-sized SignalR capacity at 3 a.m.
Two patterns dominate this type. Units scaled up for a marketing event or launch and left in place for months afterward: the capacity does its job for one afternoon and bills for the rest of the quarter. And per-environment duplication: staging and QA instances carrying the same unit count as production while serving a small fraction of the connections. Sixty days of connection-count history makes both patterns visible within a single review, because the gap between provisioned capacity and actual concurrency is right there on the chart.
Inspecting units from the portal blade
Azure portal → SignalR lists each service instance with its SKU. An instance’s Scale blade shows the current unit count, and putting the Metrics blade’s Connection Count chart next to it answers the only sizing question that matters: how much of the reserved capacity ever gets used.