Your store has a normal. Operanse learns it.
A read-only plugin that learns how your store behaves hour by hour, notices when it doesn’t, and tells you what it probably is and what it is costing. It never changes your site and never sees your customers.
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
The money arrived at the gateway and the store never completed the order. We count those from the store’s own tables, with the dollars, after a fifteen-minute grace.
The renewals that failed at 3 am
Subscriptions retried, each failure counted again, and the dashboard said 42 % failed. We know your renewal day and compare it to your renewal days, not to a Tuesday.
The shipping API that started answering 503
Every call your site makes to another service is counted by host. The hour your ERP stops answering, it is named, with the plugin that called it.
The queue that stopped draining
Renewals, emails and stock syncs run on a queue most owners never see. We say whether it is growing, draining or stalled, and how long until it clears.
The database that ran out of connections
Read from inside the plugin, on your schedule, with no agent on the box, and every reading says whose numbers they are.
The form nobody noticed had stopped
The form your sales depend on becomes a monitored series with its own normal. A stopped form is reported within about half an hour, not when someone asks why it’s quiet.
One mail, with the cause and the cost
On the Insight plan a critical incident arrives as one message: what changed, what it is worth, and a review that cites its evidence.
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: median 14 completed payments, 0 paid-but-pending (MAD 1.5). Both readings are outside the band.
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: medium.
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.
Every sentence in that mail is a stored statement the dashboard also shows. The money line is priced from your store’s own takings for that hour, and carried as an estimate.
The review is written from labelled evidence and has to cite it. It is marked as inference, and it never overwrites what was observed.
It tells you when it doesn't know
A number that rests on a guess is worse than no number. So the product declines, and says what is missing.
A metric that is a day old is not compared to a normal it does not have yet; the page says the date it will. A shortfall that cannot be priced is not priced. A reading from a shared server is labelled as the server’s, not yours.
This is the whole product in one habit: it would rather say less than say something it cannot back.
- anomaly
- forms.submitted · contact-form-7 / quote-request · stopped
- claim
- declined
- reason
- This form carries 31 % of what the store converts, but the store has 19 hours of hourly takings and pricing needs 24. The missing number is the store’s own usual takings for this hour; it will exist at 09:00 tomorrow.
- what is known
- 0 submissions in 2 h 40 m against a usual 4–9. Submissions are counted on the POST, so this count is complete, not sampled.
It won't slow your site down
It sounds like a lot of work for your site. It isn't.
When a customer visits a page, Operanse writes one line to a file and does nothing else: no database query, no call to our servers. All the real work happens in the background, on a schedule, when nobody is waiting. Pages served from your cache don’t load it at all.
The cost is measured, about two hundredths of a millisecond per page view, and the plugin shows you its own figure on its settings page.
- one line to a file per visit
- everything else runs in the background
- cached pages never touch it
- measured, and shown on the plugin’s own page
What Operanse costs a visitor’s request
Every page view: about 0.02 ms of PHP time and no extra database query. This is what 100 % of your visitors’ requests cost — hook registration and one random draw.
A sampled request: about 0.03 ms more, and no database query: the event is appended to a local file. Operanse samples 5 % of requests.
Database buffering: not in use. Nothing is written to your database on a visitor request. Events go to a private file outside your web root.
Read-only, by construction
Not a setting. There is no code path that can change your site.
The plugin can read your store. It cannot update a plugin, change a setting, run a query you did not write or touch a file. That is not a permission we withhold; the capability does not exist, on either side, and a test fails if anyone adds one.
It also never sees your customers: no names, emails, addresses, IP addresses, cookies or page URLs leave your site. Counts, statuses and amounts do.
- memory
- 61 % — this container’s memory, of its 2.0 GB limit cgroup
- load
- 3.4 on 8 CPUs — the host’s load, not this account’s shared
- database
- 12 / 151 connections — the server’s, not this site’s own shared
- disk
- 71 % used, 14.2 GB free — the filesystem the site lives on host
Ask it yourself
Every plan includes an MCP server, so your own Claude, ChatGPT or Cursor can ask the store questions. Read-only, like everything else.
Between 02:10 and 03:35 store time, 14 subscription renewals failed and the queue that runs them stalled: Action Scheduler had 212 past-due actions and zero completions for 71 minutes, then drained by 04:20. The renewals were retried by WooCommerce Subscriptions at 05:00 and 11 of the 14 completed; 3 are still failed and are listed in the incident.
The most likely cause is the stalled queue rather than the payment gateway: outbound calls to the gateway in the window answered normally, and the failures stop the minute the queue resumes. The queue runs on WP-Cron, and the heartbeat recorded a missed spawn at 02:08.
Source: cached telemetry, fresh as of 2 minutes ago · incident inc_01J9… · read-only.
The automated review on Insight needs no prompting. This is the other thing: you, asking, in your own tool, at your own cost, and getting an answer that says how fresh it is and where it came from.
Two plans, per production site
Staging is free. Seats are unlimited. There is no free plan, because a baseline on a store with no revenue is not worth learning.
- Learned baselines, incidents, alert mail
- Payments, renewals, paid-but-pending orders
- Queue, cron, integrations by host, forms
- Business impact in money
- MCP access, unlimited seats
- 30-day raw telemetry
- Everything in Monitor
- AI review of critical incidents, 6 a day per site included
- Host resources: load, memory, disk, database, PHP errors
- 90-day raw telemetry
- 14-day trial, no card
Questions owners ask
Will it slow my site down?
No, and it is measured rather than promised: about 0.02 ms of PHP per page view, no database query, no network call while a customer waits. The plugin shows the figure on its own settings page. The detail is on how it works.
Can it change anything on my site?
No. It has ten read-only capabilities and no write path. There is no update, rollback, fix or query feature, on purpose, so a bug in our product cannot become an outage on yours.
How long until it is useful?
It starts telling you things on day three. A store’s normal takes 48 hours of history to learn; a store that renews weekly takes two weeks, and the dashboard says the date on every page until then. Stopped-entirely checks work from the first day.
Does it see my customers?
No. Names, emails, addresses, IP addresses, cookies, session data and page URLs never leave your site. Order numbers, statuses, amounts and counts do.
What do I need from my developer?
Install the plugin, add two lines to wp-config.php so events are stored outside the web root and cron runs reliably, and paste a pairing code. Fifteen minutes, with the steps on the plugin’s own admin screen.
Does it work on managed hosting like Cloudways or Kinsta?
Yes. There is nothing to install on the server: the plugin reads host figures from inside PHP, and on a shared machine it says the numbers are the machine’s, not your account’s.
Start on a Friday. Know by Monday.
Pair one production store, let it learn the weekend, and read the first statements on Monday morning.