How ChangeTrace works
The path from a change on your site to an answer on your dashboard — and how long each step takes.
Almost everything ChangeTrace does happens on a schedule, in the background. Knowing that schedule is the difference between "the product is broken" and "it hasn't run yet."
The pipeline
The plugin records what happens
Two kinds of thing, collected separately:
- Changes — a plugin updated, a theme switched, WordPress core updated, the PHP version changed. Also PHP fatals, JavaScript errors and failed outbound requests.
- Sales — WooCommerce and Easy Digital Downloads orders, refunds, failed payments and abandoned checkouts, with the amount and your store currency.
Events pile into a small queue on your site and get sent every five minutes, up to 50 at a time. Nothing is sent until the batch is accepted, so a brief network problem loses nothing.
ChangeTrace checks your site is up
Every five minutes, from outside your hosting, ChangeTrace requests your homepage. This has nothing to do with the plugin — it works even when your site is completely down, which is exactly when you need it.
Sales get totalled by the hour
Every ten minutes, incoming orders are rolled up into hourly revenue and order totals per site. This is what the Overview charts read.
Once a day, yesterday gets compared to normal
At 1:00 AM UTC, ChangeTrace takes the last complete day and compares it against your own trailing 7-day average. If revenue or orders fell far enough, and by enough relative to how much your numbers normally bounce around, it opens an incident.
Every half hour, open incidents get explained
A separate job picks up incidents that have no ranked causes yet, pulls everything that changed in the 24 hours before the incident, and scores each change on how well it fits — timing, and whether errors clustered right after it.
Old data is cleared out
Once a day at 3:00 AM UTC, events and metrics older than your plan's history window are deleted. On the Free plan that is 7 days.
When each thing appears
| Signal | First appears | Then updates |
|---|---|---|
| Changes on the Timeline | ~5 minutes | Every 5 minutes |
| Revenue & Orders | ~10 minutes after the first order | Every 10 minutes |
| Site marked "Healthy" | After the first hourly heartbeat | Hourly |
| "Heartbeat Missing" | After 2 hours of silence | — |
| Outage incident | ~10 minutes into real downtime | Probed every 5 minutes |
| Sales-drop incident | After ~7 days of history, then daily at 1:00 AM UTC | Daily |
| Ranked causes on an incident | Up to 30 minutes after it opens | — |
| Performance impact of a change | ~24 hours after the change | — |
Why sales incidents are daily and not instant
A single slow hour is not a sales drop — shops are quiet at 3 AM and busy on payday. Comparing whole days against your own 7-day pattern is what keeps ChangeTrace from emailing you about normal Tuesday-afternoon quiet. The cost is that a real drop takes up to a day to surface. Outages, which are unambiguous, are reported in minutes instead.
The two halves, and why it matters
Your site talks to ChangeTrace using a site token, created when you connect and never shown again. You talk to ChangeTrace by logging in. They are completely separate: your login cannot send data for your site, and your site's token cannot read your dashboard.
Practically, this means losing your site token is not a login problem, and deleting a site does not affect your account.
{ }For developers
Plugin → API is Authorization: Bearer site_tok_…, SHA-256 hashed server-side; only the hash is
stored. Human → API is a Clerk session JWT resolved to an internal user and organization. Site
ownership hangs off the organization, never a user, which is why dashboard reads are
org-scoped and a site you do not own returns 404 rather than 403.