OPS · ANALYTICS · PERFORMANCE · 5 SEPTEMBER 2026 · 7 MIN READ
Live monitoring: the dashboard you need for four days
Peak monitoring is not analytics with a faster refresh. It is four signals, a written threshold under each one, and a named person whose job is to say something out loud.
Monitor four things and nothing else: whether the site is reachable and fast from outside your network, whether money is moving at the rate you expected, whether orders are leaving the building, and whether the integrations behind them are keeping up. Each panel needs a written threshold and a named person to call, because a number without a threshold is decoration. Build it from the tools you already pay for — Shopify's own live reporting, your uptime checker, your error tracker, your 3PL's queue — and build it in October, since a dashboard first assembled in peak week is one more thing that can be wrong.
IN SHORT
- Analytics tells you what happened; monitoring tells you whether it is still happening, and the two need different screens, different refresh rates and different audiences.
- Shopify documents Live View as showing visitors active in the past 5 minutes, customer behaviour over the last 10 minutes split into active carts, checkouts and purchases, and totals counted since midnight in the store's local time zone.
- Cumulative totals cannot fall, so they cannot warn you about anything — every panel that matters needs a per-interval rate or a ratio.
- Availability has to be measured from outside your own site, because a page that fails to load never runs the script that would have reported the failure.
- Most peak incidents surface downstream first — a fulfilment queue growing, a webhook retrying — well before revenue moves enough to notice.
- A dashboard nobody is rostered to watch at 3am is a screensaver; the rota is the monitoring.
Monitoring is not analytics with a faster refresh
The two get conflated every year and the result is a peak screen full of figures nobody can act on. Analytics answers questions about a period that has finished: which channel performed, what the conversion rate was, whether the campaign paid. Monitoring answers one question about right now — is the thing working — and it is read by someone who may have to wake a developer up.
The practical difference is the decision attached. If a panel changes colour and nobody knows what to do, it does not belong on the monitoring screen. Put it on the analysis dashboard, where it can be argued about in December.
That test removes about two-thirds of what usually ends up on these screens. Traffic by channel, new versus returning, average order value, basket composition: all genuinely interesting, none of them actionable between Thursday and Monday. Your four days of monitoring want a screen small enough that a tired person can read it in one glance and say "that one is wrong".
The four signals, and where each one comes from
Everything worth watching falls into one of four categories, and each has a natural source you almost certainly already have.
- Demand — is traffic arriving? Shopify's Live View is built for exactly this. Shopify documents it as showing visitors active on the store in the past 5 minutes, a customer behaviour panel covering the last 10 minutes broken into active carts, checkouts and purchases, plus totals for sales, sessions and orders counted since midnight in the store's local time zone. It also warns that its figures can differ from third-party analytics because of counting methods, bot filtering, script and cookie requirements, time zones and consent.
- Money — is it converting? Orders and revenue per interval, and, more usefully, the ratio between checkouts started and purchases completed. A payment method quietly failing shows here as a widening gap long before the revenue total looks unusual.
- Delivery — is the site up and fast? Availability and response time for the home page, a collection, a product page and the cart, measured from outside. Plus the client-side error rate if you collect one.
- Downstream — are orders leaving? Unfulfilled order count and its rate of change, failed or retrying webhooks, the queue depth between you and your 3PL or ERP, and inventory sync lag. This is the category that actually breaks, and the one most peak dashboards omit.
Rates and ratios, never cumulative totals
A number that counts up from midnight cannot go down, which means it cannot warn you about anything. At 2pm on Black Friday your revenue-since-midnight panel will look magnificent for the entire hour that checkout is broken. This is the single most common design fault in a peak dashboard, and it is why the totals in Shopify's Live View are context rather than an alarm.
Every panel that is meant to raise an eyebrow should be either a rate per interval — orders in the last 15 minutes, errors per minute — or a ratio that holds roughly steady regardless of volume. Ratios are the better instrument because they survive a traffic spike: sessions tripling is not a problem, but sessions tripling while checkout starts per session halves is the same problem you would have seen at 3am, only louder.
If you sell internationally, note that Live View's daily totals reset at midnight in the store's local time zone, not the customer's. A US trading peak read from a store set to Europe/London crosses the reset in the middle of the evening. Know which clock every panel is on before you compare two of them.
Measure availability from outside your own site
Client-side instrumentation cannot report the failure that stopped the page loading. If the storefront returns an error or a network route to your CDN degrades in one region, the script that would have told you never executes. Everything you learn from inside the page is conditional on the page working.
So the availability panel should come from a synthetic check running somewhere else: a scheduled request to a handful of real URLs from at least two regions, recording status code and time to first byte. A cart or checkout-start check is worth the effort to configure, because the most expensive outages are the ones where the marketing pages are perfectly fine.
Alongside it, keep links to the status pages you depend on — Shopify's, your payment provider's, your 3PL's, your email platform's. A surprising share of peak incidents are somebody else's, and the fastest possible resolution is knowing within two minutes that there is nothing for you to fix. Put the links on the dashboard, not in somebody's bookmarks.
Thresholds are written in October, in numbers
Under every panel goes one line: what normal looks like, what triggers a look, what triggers a call. Written in advance, in figures, by the people who will not be awake when it fires.
Deriving "normal" is less scientific than it sounds and that is fine. Take last year's equivalent hours, adjust for whatever you know about this year's plan, and round generously. The point of the threshold is not accuracy; it is that the decision to act was made calmly by someone with the context, rather than at 4am by someone guessing whether a 30% drop between 3 and 4am is meaningful. It usually is not. A 30% drop at 7pm on the Friday is a different conversation, and if your threshold is a single number it will mislead you at one end of the day or the other.
Two thresholds per panel is the practical shape: a daytime band and an overnight band. Anything more elaborate will not be maintained.
Alert on the few things, glance at the rest
Alerting and dashboarding are different mechanisms and mixing them up produces the worst outcome in operations, which is a team that has learned to ignore notifications. By hour six of a peak weekend, a channel that has cried wolf twice is a channel nobody reads.
Alert on the handful of conditions that are unambiguous and urgent: the site is not responding, checkout errors have crossed the line, orders have stopped flowing downstream for longer than the retry window, payment authorisation is failing. Four or five conditions, each one pointing at a named scenario in the runbook, each one routed to a phone rather than a chat channel.
Everything else lives on the screen and is read by whoever is on shift. The distinction to hold: an alert says "wake up"; a dashboard says "this is what the store is doing". Only the first has the right to interrupt.
The rota is the monitoring
The dashboard is the cheap part. What makes it work is somebody rostered to look at it, with a name, a start time, an end time and the authority to escalate without asking permission first. Every failed peak retrospective contains the sentence "the graph did show it, but".
Write the shifts down before the week starts, including the unglamorous ones. Include a handover note between shifts — three lines is enough: what I saw, what I changed, what I would keep an eye on. It takes ninety seconds and it is the difference between the 6am shift starting informed and starting from scratch.
And give the person on shift explicit permission to be wrong. A team that punishes false alarms gets silence instead, which during peak is considerably more expensive than a phone call that turned out to be nothing.
What we would talk you out of
Do not build a custom dashboard in November. Assembling data from four systems into one bespoke screen is a project with its own bugs, its own deploy, and no time left to prove it. If it did not exist in October, compose the view from the tools you already have — Live View in one tab, your uptime checker in another, the fulfilment queue in a third. Three tabs somebody trusts beat one beautiful screen nobody has verified.
Do not add a new monitoring vendor in the run-up either. Whatever it shows you, you have no baseline for it, and a tool you cannot read at a glance is a tool that will be ignored under pressure. Buy it in February and spend the year learning what its numbers look like when everything is fine.
And do not put the dashboard on a television and call that monitoring. An office screen is good for morale and shared awareness during working hours. It is not a rota, it is not an alert, and there is nobody in the room at 3am on the Saturday — which, going by the incidents we get called about, is roughly when it matters.
Questions this raises
What should you monitor during peak trading?
Four signals: site availability and response time measured from outside your network; the rate at which orders and revenue are arriving, plus the ratio of checkouts started to purchases completed; the error rate on the paths that take money; and the downstream flow of orders into fulfilment, including webhook failures and queue depth. Each one needs a written threshold and a named person to contact.
Is Shopify Live View enough on its own?
It covers demand well and nothing downstream. Shopify documents Live View as showing visitors active in the past 5 minutes, behaviour over the last 10 minutes split into active carts, checkouts and purchases, and totals since midnight in the store's local time zone. It will not tell you that fulfilment pushes are failing or that the site is unreachable from one region, and those are the incidents that cost you money after the fact.
Why does a revenue total make a poor alarm?
Because a cumulative figure only ever rises. A revenue-since-midnight panel looks healthy throughout an outage, since it simply stops climbing rather than falling. Use a per-interval rate or a ratio that holds steady across volume changes, so the shape of a problem is visible regardless of how much traffic is arriving.
How many alerts should a peak setup have?
Four or five, each unambiguous and urgent, each mapped to a named scenario in the runbook, each routed to a phone rather than a chat channel. More than that and the team learns to ignore them by the second night, which leaves you worse off than having no alerting at all.
Should we build a custom monitoring dashboard before Black Friday?
Not if you are starting in the autumn. A bespoke screen pulling from several systems is a build with its own defects and no time to earn trust. Compose the view from tools you already use and already read correctly. Build the custom version in the quiet part of the year, when you can run it for months and learn what normal looks like on it.
Who should be watching the dashboard?
A named person per shift, with the authority to escalate without seeking approval, and a short written handover to the next shift covering what they saw, what they changed and what to keep an eye on. The screen is the cheap part; the rota is what turns it into monitoring.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.