Features · Investigate problems
Replay the day it went wrong.
Pick a day and watch it happen again: orders and payments against the store’s usual for each hour, the change that came first, and the alerts at the minute they were sent. Operational events only; no visitor is recorded.
On Monitor and InsightServer CPU and memory rows on Insight.
- 09:12ChangePayment gateway plugin 8.1 → 8.2administrator · a marker across every row
- 09:30WarningOrders thin to a fraction of the usual; payments failing
- 10:00CriticalMessage sent: the row turns red at this minute
- 10:38ResolvedOrders back inside the usual range
Try it: four days, replayed
Choose a day, press play, and pause or let it run. These are fictional stores built to show the shape of each problem; your own replay uses your store’s recorded events.
The gateway update. Orders thinned to nothing eighteen minutes after a payment gateway update, while every payment rang as failed. Caught at 09:30, messaged at 10:00, back when it was rolled back. See the full example
- 09:12Change recorded: Payment gateway plugin 8.1 → 8.2 · by an administrator (wp-admin)
- 09:20PHP errors · Unusual: 2 warnings since 09:12, usually none at this hour
- 09:30Orders · Warning: 0 orders in the last 15 minutes, against about 10 normally · added to the daily digest, no alert sent
- 10:00Orders · Critical: orders well below normal for 30 minutes · alert sent · message sent
About $1,100 has not been taken since 09:30, against this store’s usual for the hour. Carried as an estimate. - 10:26Change recorded: Payment gateway plugin rolled back to 8.1 · by an administrator (wp-admin)
- 10:38Orders · Resolved after 68 minutes: back to normal
- 07:54Change recorded: Forms plugin 3.4 → 3.5 · by an administrator (wp-admin)
- 08:45Quote form · Warning: no submissions for 45 minutes, against about 10 normally · added to the daily digest, no alert sent
- 09:30Quote form · Critical: no submission for 90 minutes on a form that usually has about 20 by now · alert sent · message sent
No quote request has arrived since 08:00; about 20 would have by now. Orders, payments and errors are inside their bands; the forms plugin update at 07:54 is the only recorded change. - 09:48Change recorded: Forms plugin rolled back to 3.4 · by an administrator (wp-admin)
- 10:04Quote form · Resolved after 79 minutes: 5 submissions since the rollback, back to normal
- 12:00Orders · Unusual: 12 orders in the last 15 minutes, against about 7 normally · busier than usual, not a fault
- 12:10CPU · Warning: 85 % on a host that sits near 22 % at this hour · added to the daily digest; an alert if it holds 90 % for 15 minutes · Insight
- 12:15Checkout · Unusual: 6.4 s to place an order at the median, usually about 1.3 s · memory at 88 %
- 12:25PHP errors · Warning: 5 fatal errors in 5 minutes, memory exhausted, usually none · added to the daily digest, no alert sent
- 12:30CPU · Critical: CPU at or above 90 % for 15 minutes · alert sent · message sent
The host is saturated: CPU 97 %, memory 99 %, checkout at 6.4 s, and no order has been placed since 12:22. No change is recorded today. - 12:35Orders · Warning: 0 orders in the last 15 minutes, against about 6 normally, after 36 in the half hour before · added to the incident alerted at 12:30
- 13:05Orders · Critical: orders well below normal for 30 minutes · alert sent · message sent
About $980 has not been taken since 12:35, against this store’s usual for the hour. Carried as an estimate on the same incident. - 13:15Host · Back near usual: CPU 35 %, memory 63 %, no fatal error since 13:10
- 13:25Orders · Resolved after 75 minutes: the server and the orders both back to normal
- 02:10Renewals · Warning: 14 of 38 renewals failed in the two o’clock batch, usually 1 or 2 · added to the daily digest, no alert sent
- 02:15Job queue · Unusual: 30 actions past due, usually 1 or 2; 14 renewal payments are scheduled to retry
- 02:30Renewals · Still open: no failure outside the batch since 02:15, too few for an alert · no alert sent
- 04:20Job queue · Back to normal: the queue drained to 2 past due
- 05:00Renewals · Retries: 11 of 14 went through on the first retry; 3 are due again at 17:00
- 05:10Renewals · Resolved after 180 minutes: 35 of 38 collected, 3 on retry · in the 08:00 digest, no alert sent
A chart shows that something happened, not the order it happened in
What an owner remembers of a bad day is a sequence: orders stopped at half past nine, the first message came at ten, and it was the gateway update. A dashboard of separate charts makes you rebuild that sequence by hand, and a developer arriving later sees none of it.
- Several charts, each correct, and no single account of the morning.
- Arguments about whether the alert came late or the problem started early.
- A developer asking “what did you see?” after the fact.
What you can see
Normal beside observed
Every row is drawn against the store’s own usual for that hour. When orders stop, the orders the store would normally have taken are drawn faintly where they should have been, so a quiet hour and a broken hour look different.
≈ $1 240 shortfall, priced from this store's own takings
Changes as markers
Each recorded change is a marker across the day, with the role and source that made it, so the plugin update at 09:12 sits exactly where it happened against orders, payments and errors.
- 09:12ChangePayment gateway plugin 8.1 → 8.2administrator · wp-admin
- 10:26ChangePayment gateway plugin rolled back to 8.1administrator · wp-admin · made by the store, not by Operanse
Alerts as they were sent
A row changes colour only where a problem was recorded at the time, and turns red at the minute a message went out. Playback does not judge the day again, so a replay never calls something critical that nobody was told about.
- 09:30WarningOrders below the usual range for Tuesday 09:00
- 10:00CriticalOrders stopped. Message sent to email and Slack.
- 10:38ResolvedOrders back inside the usual range
A replay is a link
Send it to whoever is fixing the problem, and they see the same day you did.
- day
- Tue 14 Oct, store time
- starts
- twenty minutes before the first incident, or wherever you choose
- rows
- revenue against usual, orders, payments, checkout time and errors, renewals, forms, scheduled actions, outbound calls, PHP errors; server CPU and memory on Insight
- controls
- play, pause, speed, drag through the day, zoom from the day to one hour
A store’s own events and timings, reported from its own code, can be added as rows of their own.
Coverage and limits
What it covers
- Playback. Replay any day: orders, payments, renewals, forms, scheduled actions and changes on one timeline, against the usual.Monitor
- History. 7 days on Watch, 30 on Monitor, 90 on Insight.All plans
Limits
- It replays what the store recorded. A page served from cache, or a visitor who left, is not an event and is not in it.
- No visitor data: it is not session recording, and nothing about who visited is in any replay.
- Playback is on Monitor and Insight, over the history the plan keeps: 30 or 90 days.
Start using it
- Install the plugin from wordpress.org. It is read-only: it cannot change the site.
- Pair the site with the token from your dashboard. Setup, step by step
- Every day from pairing on can be replayed, as far back as your plan keeps history.
Monitor On Monitor and Insight. Server CPU and memory rows on Insight. Compare plans
Questions
Is this session replay?
No. It replays the store’s operational events (orders, payments, renewals, forms, scheduled actions, calls, errors and changes). It records nothing about visitors or what they saw.
Why does a replay never disagree with the alert?
Its colours come only from the alerts raised at the time. It does not judge the day again with hindsight.
How far back can I replay?
Over the history your plan keeps: 30 days on Monitor, 90 on Insight.
Are the days above real stores?
No. They are generated in your browser to show four common shapes of problem. Each links to a written example of the same kind of day.