Your store has a normal. Operanse learns it.
Operanse learns how your WooCommerce store normally runs, hour by hour: orders, payments, renewals, background tasks and the services it connects to. When something goes wrong, it tells you, estimates the revenue at risk and shows what changed just before. A read-only plugin: it never changes your site.
Built and run on a WooCommerce store taking about $100,000 a day.
Orders created. A checkout that stopped converting after a gateway update, with no error page anywhere.
Six of the things it learns on every store. Your dashboard draws each one against your store’s own normal for that hour.
The part of your store nobody sees
WooCommerce shows you what was sold. It doesn't show you whether the machinery behind the sales is keeping up.
| What WooCommerce shows you | What Operanse adds | |
|---|---|---|
| Orders | A list, and a report by day | Spot orders that stop arriving, and the revenue it is costing |
| Payments and renewals | Failed orders, one at a time | Catch unusual payment failures and renewals that fail or never run |
| Background tasks | A table of scheduled actions, if you know where to look | See when the tasks behind renewals, emails and stock updates fall behind or stop |
| Connected services | Nothing | Find the shipping, payment or other service that is failing, and the plugin calling it |
| Order emails | Nothing, until a customer asks | Know when order emails fail to send, and why: the mail server refusing them, rejecting the login or not answering |
| Changes | Nothing | See what changed on the site, and who changed it, before a problem started |
Each one learns its own normal for every hour of the week, so a quiet Sunday evening is fine and a quiet Tuesday lunchtime isn’t.
Most of that normal is learned in 48 hours. A store that renews weekly needs two weeks to see a full renewal cycle, and every chart says when its normal will be ready. Checks for something that has stopped entirely work from the first day.
Charts and Playback are on Monitor and Insight.
The day, replayed as it happened
Replay your store's day to see when a problem started, what changed just before it, and when things returned to normal.
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
What a ping can't see
Uptime checks tell you the home page loads. These are the things that go wrong while it does.
The order that was paid and never moved
A customer pays and WooCommerce leaves the order pending. Operanse counts paid orders that never moved, and the money in them.
The renewals that failed at 3 am
A renewal batch fails overnight while the storefront looks fine. Operanse knows your renewal day and counts each renewal once, so retries don’t inflate the failures.
The shipping service that stopped answering
A shipping provider or another service your site connects to starts failing. Operanse names the service and the plugin making the calls.
The background tasks that stopped running
Renewals, emails and stock updates run as background tasks most owners never see. Operanse tells you when they fall behind or stop.
The database that ran out of connections
When the database runs short of connections, pages slow down and orders fail to save. On Insight, Operanse reads the server under your site from inside the plugin, with nothing to install on the server.
The form nobody noticed had stopped
A quote or enquiry form stops receiving submissions. Operanse notices the unusual silence within about half an hour, instead of waiting for someone to miss the leads.
The confirmations that stopped going out
A mail password changes or the email service goes down while orders keep coming in. Operanse sees each send fail and says why: the server refused it, rejected the login or never answered. It also notices when sending goes quiet. It watches the send, not the customer’s inbox.
The afternoon the storefront got slow
Checkout becomes unusually slow while the rest of the site seems fine. Operanse measures what shoppers experience apart from admin and background work.
Built specifically for WordPress and WooCommerce
We run our own stores on it, so every check comes from something that actually went wrong.
Operanse knows WordPress from the inside: the background task queues, the mail plugin that refused a send, the contact form that quietly stopped, the database connections under it all.
That shows most clearly with WooCommerce Subscriptions. A subscription store can look healthy while its renewals fail at night. Operanse watches failed renewals, active subscriptions, recurring revenue and the background tasks renewals run on. It knows when your renewals normally run, so a Monday batch is compared with other Mondays, and a card retried four times counts as one failed renewal, not five. How renewals are judged
Know what went wrong and what it could cost
On Insight, a critical incident arrives as one message: what happened, the estimated revenue impact, and the likely cause with the evidence behind it.
CRITICAL open since Tue 14:21 (store time)
What changed
9 orders carrying a Stripe transaction id have been pending for more than 15 minutes, totalling $1,180. Completed payments in the last hour: 2, against this store’s usual 11–17 for a Tuesday afternoon.
Comparison
This store’s own normal for Tuesday 14:00–15:00, learned from 6 weeks of history: usually 14 completed payments and no paid-but-pending orders. Both readings are outside this store’s normal range.
What this is worth
Priced from this store’s hourly takings: a shortfall of about $1,240 over 3 hours, carried as an estimate. Renewals due in the window are included; retries are not counted twice.
AI review (evidence-cited)
The orders were paid at Stripe and the store did not complete them. The site’s own calls to api.stripe.com answered normally through the hour [E3], so the outbound side is healthy; what stopped is the inbound completion. A recorded change at 13:58 updated WooCommerce Stripe Gateway 9.4.1 → 9.5.0 [E5], 23 minutes before the first stuck order [E1]. Likely cause: the gateway’s webhook handler is no longer completing payment on this store since the update. Confidence: moderate.
What Operanse did not verify
Whether Stripe’s side reports the webhook deliveries as failed, and whether the update changed the webhook signing secret. Both are visible in the Stripe dashboard, not from the store.
Operanse keeps what it observed apart from what it thinks is the likely cause, and says what it could not verify. The revenue impact is an estimate, priced from your store’s own history.
It won’t guess when the evidence isn’t strong enough. It tells you what it knows, what it suspects and what it can’t yet determine.
An alert means “this is unusual for your store, take a look”, not “this is definitely broken”. Some will turn out to be nothing; waiting for certainty would mean hearing about real problems later.
Send alerts via
- Slack
- SMS
Each person picks where their alerts go and which levels they hear.
Read-only, by construction
Not a setting. There is no code path that can change your site.
Customer personal information stays on your site: no names, emails, addresses, IP addresses or cookies leave it. Counts, statuses and amounts do.
A page view costs about 0.02 ms of PHP, measured, with no database query and no call to our servers; everything else runs in the background. How it’s measured · Security
Ask it yourself
Connect Claude, ChatGPT or Cursor to your store's monitoring and ask about it in plain words.
Likely cause: the background queue that runs renewals stalled, not the payment gateway. WP-Cron missed a run at 02:08, and from 02:10 to 03:35 no scheduled action completed while 14 renewals failed. Calls to the gateway answered normally throughout, and the failures stop the minute the queue resumes.
11 of the 14 went through on the 05:00 retry; 3 are still failed and are listed in the incident.
Source: cached telemetry, fresh as of 2 minutes ago · incident inc_01J9… · read-only.
Every answer cites its evidence and says how recent the data is.
To connect, sign in with your Operanse account. Team members only see the sites they have access to.
A read-only MCP connection, on both paid plans.
Free for one site, then priced per site
Every new site starts with the 14-day trial, or chooses Watch instead. A trial that ends without a card drops to Watch, not to a locked account.
- One site, uptime checked every 5 minutes
- The last payment method switched off, the checkout, cart or shop page drafted or deleted, every product out of stock: mailed within about ten minutes
- Scheduled tasks falling behind, scheduled actions failing, renewals failing
- Alerts to two emails, and a weekly report
- 7 days of history
Need to catch failing payments, broken integrations or a drop in revenue? That is Monitor.
Sign up free- Learned baselines, incidents, alerts by mail, Slack, SMS and WhatsApp
- Payments, renewals, paid-but-pending orders
- Background tasks, cron, connected services, forms, outgoing mail
- Business impact in money
- Playback: any day replayed one event at a time, with the alerts as they were sent
- MCP access, unlimited seats, members can be limited to certain sites
- 30-day raw telemetry
- Everything in Monitor
- AI review of critical incidents by top-tier AI models, 6 a day per site included
- Server resources: load, memory, disk, database, PHP errors, and CPU and memory lanes in Playback
- 90-day raw telemetry
- 14-day trial, no card
Questions owners ask
How long until it is useful?
Checks for something that has stopped entirely work from the first day. Most of a store’s normal takes 48 hours of history to learn, so the rest starts on day three; a store that renews weekly takes two weeks to see a full renewal cycle. Until a series is ready, its chart says the date it will be. The 14-day trial covers both.
What do I need from my developer?
Possibly nothing. Installing the plugin and pasting a pairing token is enough to start, and takes about five minutes. Two optional lines in wp-config.php, which keep events outside the web root and make cron run reliably, are worth adding on a busy store; the plugin’s admin screen says when they would help and shows the exact lines, and getting started walks through them.
Will every alert be a real problem?
No, and that is by design. Operanse flags what is unusual for your store so someone can look, rather than waiting until something is certainly broken. Some alerts will turn out to be a quiet hour or a run of ordinary card declines. Each one says what it saw and how far that is from your normal, so checking takes a minute. A critical alert needs both a reading well outside your normal and a real count behind it, so five failed payments on a quiet night are a warning, not a message at 3 am.
Does it work on managed hosting like Cloudways or Kinsta?
Yes. There is nothing to install on the server: the plugin reads server figures from inside PHP, and on a shared machine it says the numbers are the machine’s, not your account’s.
My store has custom code. Can it report into Operanse?
Yes. Six WordPress actions let your own code report a form, an event, a timing, an integration call or an error, and each one lands where the built-in kind does. If the plugin is not installed the call does nothing, so it is safe to leave in. The six actions are in the documentation.
More on pricing, security and how it works.
Know when your store isn’t running normally.
Pair one production store today. It watches for anything that stops from the first day, and knows your store’s normal within two.