Troubleshooting

Start with the plugin's own view of itself. In wp-admin it is Settings → Operanse; on the command line:

wp operanse status

The dashboard's site page says the same things from our side, under Connection and uptime.

The dashboard says the plugin is not connected

Not paired yet. Settings → Operanse shows Paired: no. Create a pairing token on the site's overview page and paste it. See install.
Paired, but nothing arrives. The heartbeat runs on WP-Cron. If Last heartbeat is old, cron is not running: see the next section.
Paired: no, with a note that the site's `AUTH_KEY` changed. The plugin encrypts its credentials with WordPress's own salts. If the salts were rotated, the secret cannot be read. Pair again with a new token; nothing else needs doing.
Backoff until shows a time in the future. The plugin failed to reach Operanse several times and is waiting before retrying. Check that the server can reach api.operanse.com over HTTPS; a firewall that blocks outbound requests from PHP is the usual cause.

WP-Cron is not running reliably

The notice means the plugin's own check could not reach the site's cron endpoint, or a scheduled collection ran late. The fix is a system cron: set DISABLE_WP_CRON and run cron every minute from the server. Then:

wp cron test
wp operanse cron-check

A site behind HTTP authentication, a maintenance page or a CDN challenge fails the built-in loopback request, and so does one whose own domain does not resolve from the server. A system cron does not depend on any of that.

Operanse is buffering events in your database

The plugin could not find or prove a private directory for its buffer, so it is using a table in your database, which costs a query on the requests that produce events. Set OPERANSE_DATA_DIR in wp-config.php to a directory outside the web root. The server setup page has paths for common hosts. If the constant is set and the notice stays, the page says why: the path is inside the document root, or PHP cannot create or write to it.

A variant says the plugin could not prove that a directory under wp-content/uploads is unreachable. A blocked loopback request, a CDN or firewall challenge and a genuinely public uploads folder all look the same from inside the site, and the plugin will not store telemetry anywhere it cannot prove is private. The constant settles it.

Uptime says "not reachable: not connected, or blocked"

Our uptime check fetches the home page and the plugin's status address. If the site is up but the plugin's address is reported as not reachable, something between us and the site is refusing the request: a firewall, a bot-protection rule or a CDN challenge. Allow requests whose user agent begins operanse-uptime/. The status address answers only when the site is paired, so an unpaired site is also reported this way.

The stream shows "not connected (falling back to cron polling)"

The wp operanse stream process is not running, or it stopped. Check the service or the cron line that starts it, and its log. Nothing is lost: read jobs arrive through cron polling until it is back. See connection modes.

An alert did not arrive

The Deliveries tab under Alerts shows every message and where it stopped.
A recipient must confirm before it receives anything. An unconfirmed recipient is listed as such.
Each recipient has a minimum severity. A recipient set to critical only does not get warnings.
SMS and WhatsApp carry critical alerts only, and each organisation has a daily allowance.
Quiet hours hold warnings and information; critical alerts still go out.

Learned monitoring has not started

Most baselines need 48 hours of continuous data, and a store whose renewals run weekly needs two weeks of them. The site page shows when each will be ready. Until then, fixed rules apply and each alert they raise states the threshold it used. A gap in the data, such as cron stopping for a day, extends the wait.

Something is missing from what Operanse sees

An outbound call to a service. Calls made with cURL directly or through a vendor SDK's own client do not go through the WordPress HTTP API and are not seen. Report them with the operanse_integration action; see reporting from your own code.
A form. WPForms, Gravity Forms and Contact Form 7 are recognised. A form your own code handles is reported with operanse_form_submitted.
Cached pages. A page served from a full-page cache never loads WordPress, so it is not sampled. That is intended: it costs nothing and there is nothing to observe.
A server figure marked shared. On a shared host, load and memory describe the whole server, not your account's share. The figure is kept because a busy server still explains a slow site, and every alert says which scope it is.

Getting help

Email contact@operanse.com with the site's address and the output of wp operanse status. The output contains no customer data.