How it works

Install, two lines, pair

Operanse is a WordPress plugin (download) and a hosted service. Install the plugin, then set two things in wp-config.php. Both are checked by the plugin itself and reported as an admin notice until they are in place.

// A private directory OUTSIDE your web root that PHP can write to.
define( 'OPERANSE_DATA_DIR', '/home/youruser/operanse-data' );

// Run cron from the system, not from visitor requests.
define( 'DISABLE_WP_CRON', true );
// * * * * *  cd /path/to/wordpress && wp cron event run --due-now --quiet

Then create the site in the dashboard, which gives you a one-time pairing code; paste it into the plugin. The plugin receives its own credentials, and from that point every request it makes to us is signed. Nothing inbound is required: the plugin calls out, on its schedule, and the dashboard is read from our side.

The first thing it sends is an inventory: WordPress, PHP and database versions, plugins and themes with versions, WooCommerce configuration (gateways by id, never credentials), scheduled tasks, REST routes. Every later inventory is diffed against the last, and that diff is what a review means by “a recorded change at 13:58”.

What it observes

Events are appended to a local spool file and uploaded in gzipped batches by cron. The service validates every event against a schema and a per-type attribute allow-list, redacts free text a second time, deduplicates, and rolls the events up into one-minute, five-minute, hourly and daily series.

How a normal is learned

For every metric and every environment, the service learns a median and a median absolute deviation per hour of the week from the five-minute series. A reading is compared to that band, not to a threshold someone typed. Low-volume counters get a second detector that sums the last hour against the sum of its expectations, so a store that takes six orders an hour is judged fairly. A counter that has gone to exactly zero for longer than it ever has before is reported as stopped, judged against its own rate beforehand and against the rest of the site in the same hour, so a quiet midnight does not page anyone.

A baseline needs 48 hours of continuous data. A store whose renewals run weekly needs two weeks, and the dashboard reads the renewal schedule from WooCommerce Subscriptions to know that. Until a baseline is ready the site page says so above every tab, with the date, and the universal rules that apply meanwhile name their window and basis in the sentence.

Incidents, money, review

Signals within thirty minutes on one environment form one incident; downtime leads. Every open anomaly is given a business impact from the store’s own hourly takings: a priced shortfall on a revenue-bearing metric, an exposure figure otherwise, or a refusal that names the missing number. Nothing multiplies a load average by anything.

On Insight, a critical incident triggers one review. The review is produced from labelled evidence records, every statement in it must cite evidence that exists, the validator rejects it otherwise, and the result is stored as inference beside the observed facts, never over them. Six a day per site are included; more are metered at $1.50 and off unless you set a ceiling. On Monitor the same investigation runs with the deterministic planner and no model call.

What it costs the site, measured

Nothing runs in a visitor’s request except one append to the spool under flock. Collection, upload, discovery, the host collector and job polling all run from cron. A page served from your cache never loads the plugin at all, which is also why page views are not something this product counts.

The number was measured, not estimated: a 200-request benchmark against a control arm with the plugin deactivated counted zero outbound HTTP calls attributable to the agent, and a page view costs about 0.02 ms of PHP time and no database query. Whole-request timing on a 460 ms store cannot resolve a difference that small, and the benchmark prints NOT RESOLVED rather than claim one; what resolves at that scale is counting queries and network calls, so that is what is claimed. The host collector runs to a two-second budget per cron run, caps the error log at 1 MiB, and sends its own wall time on every reading.

The one case that costs more: if the plugin cannot find a private directory outside the web root, it buffers events in one bounded database table, which is a SELECT and an INSERT on the request that produced each order, payment or form event, about 1.8 ms. The admin notice says so, cannot be dismissed, and the one OPERANSE_DATA_DIR line above removes it on the next page load.

The host, with nothing installed

A PHP process can read its own host without privilege: /proc, the cgroup files, disk_free_space(), SHOW GLOBAL STATUS, opcache_get_status(), and the error log its own PHP wrote. What it cannot know is whose numbers they are, so the collector decides a scope once per run and every family carries it.

• cgroup — a container; the limit is the site’s own limit.
• host — a machine the site has to itself: a VPS, a droplet, a dedicated box.
• shared — a box the site shares. The number is kept, because a host at load 40 is still why the site is slow, and every sentence says it is the host’s. The account’s share is never guessed.
• unreadable — Windows, open_basedir, a disabled function; reported with the reason, like the spool tier is.

On a managed VPS such as Cloudways the figures are your own server’s and nothing needs installing. Web-server access logs and syslog are not read: they need root and they are full of visitor IPs and URLs. The PHP error log is read because it is the one log without a visitor in it, through the redactor, with paths reduced to file names.

How a read job reaches the site

When the dashboard, an MCP client or a review needs a live read, it creates a job from the fixed list of read capabilities. Three transports deliver it: the plugin polls for jobs on cron (the default, works everywhere); the plugin holds an outbound stream so jobs arrive in seconds (wp operanse stream, for hosts where you can run a process); or, if you choose to enable it, a signed inbound request to the plugin’s REST endpoint. All three run the same closed capability list through the same executor with the same audit record.

What it deliberately does not do

• No visitor-level anything: no URLs, referrers, cookies, sessions, IPs or identifiers exist in telemetry. Visitor analytics is a different product.
• No remediation: no updates, rollbacks, fixes or snippets. Mutation is absent by construction, not switched off.
• No log ingestion beyond the PHP error log’s counts and three redacted samples per level.
• No synthetic checkout: we observe the orders that were created, failed or stalled; we do not place test orders. A front-end script failure that produces no event is seen when the order count stops, which is about thirty minutes.
• No automatic monitors: a form the product thinks matters is proposed, and an owner or admin confirms it.

Reference material lives at docs.operanse.com.