Changelog

The free Checkout Health Check used to ask for an email address before it would start, and sent the results link there. It now asks for your store address and nothing else.

• Results on screen. The page shows where your check stands in the queue, then a progress bar and each of the four steps as it finishes. The results appear in place when the check is done.
• Email only if you want it. While the check is going, you can give an email address and we send you the link when it finishes. If you do not, we never ask again.
• Your last check, remembered. The tool page offers the link to your most recent check for seven days, in the browser you used.
• The same limits. Up to ten checks a day from one network, and the link and its screenshots are deleted after seven days.

The picture that comes with a change is now the page itself.

• The page as it looks now. The picture is the screenshot taken after the change, as sharp as it was captured, with a yellow box around each part that changed. Nearby changes share a box, so a reworded line is one box, not one per letter.
• Why it changed. The old picture marked every changed pixel in red over a faded, slightly blurred copy of the page. When a whole sentence was replaced, the old and new words were drawn in red on top of each other and read as nothing.
• Everywhere you see a change. Change alert emails, Slack messages and shared reports all carry the new picture. On a check's page the view is now called What changed.
• Older checks keep their picture. Checks recorded before today still show the picture they were saved with.

We now show the cookie consent banner only to visitors in Europe, where the law asks us to get consent first. The privacy policy, effective today, says so.

• In Europe, nothing changes. The banner appears on your first visit. The cookies that measure visits and our ads, OpenAI's pixel and our own attribution cookie all wait for your choice.
• Elsewhere there is no banner. Visit measurement and the measurement of our ads on Google and in ChatGPT are on when you arrive, as the privacy policy describes.
• You can turn it off wherever you are. Cookie settings in the website footer opens the same choices as the banner.
• Global Privacy Control still wins. If your browser sends it, none of this measurement happens, wherever you are.
• A shorter banner. It now says what our cookies are for in two sentences, and the switches for each kind of cookie sit behind Customize.

The free Checkout Health Check used to stop at add to cart on any product that needed a choice first, and mark the step as not checked. Monitors set up with guided setup already chose for you; the free check now does the same.

• It chooses as a shopper would. The first available size, colour or quantity in each option, then add to cart, then the cart. The add-to-cart step says what was chosen.
• It says when it could not. If a page will not take the choice, the step is marked as not checked, as before, rather than reported as a problem with your store.
• Paste any address. If you give it your cart or checkout address, it starts from your homepage, since that is where a shopper starts.

We now advertise in ChatGPT as well as on Google, and the privacy policy, effective today, says how we measure those ads.

• Only with your consent. OpenAI's measurement pixel loads only if you accept marketing cookies in the consent banner. Without that, it does not load and OpenAI receives nothing from it.
• What it sends. The address of each page it loads on, and word when you create an account or start a free check, so we can count which ads lead to those. It never loads on a free check's results page, whose address is your private link to it. Every event asks OpenAI not to use it for personalisation.
• How it matches. To tell whether you came from one of our ads, the pixel reads contact details you type into our sign-up or free check form, such as your email address or name, turns them into a one-way code (a SHA-256 hash) in your browser, and sends OpenAI only that code, never the details themselves. We pass it nothing else about you.
• Three cookies. __oppref records, for up to 30 days, that you arrived from one of our ads in ChatGPT. __obref is a random reference for your browser on our site, kept for up to a year. __oaiq_consent records your consent, for up to 30 days.
• The public website only. As with Google Analytics and Google Ads, nothing from the signed-in app reaches it.
• Change your mind at any time from Cookie settings in the website footer. Withdrawing consent deletes all three cookies.

Updated later on October 6 to say how the pixel matches sign-ups and free checks to our ads. The first version of this entry said we pass it nothing about you, which stopped being true once the pixel was switched on: OpenAI turns this matching on for our pixel, with no way to turn it off.

Three things about our emails, fixed.

• Buttons look like buttons everywhere. Outlook on Windows ignored the padding around our buttons, so "Open your dashboard" arrived as a violet highlight around the words. Every email now draws its buttons in a way Outlook understands too, with room around the label and rounded corners. The sign-up, password reset and invite emails, which said "if the button does not work" without having a button, now have one.
• Alerts carry their screenshot. A change alert pointed at its picture instead of including it, and that picture is only shown to someone signed in, so inboxes showed a broken image where the change should have been. The picture of what changed now travels inside the email, and so does the screenshot of the step that failed in a failure alert, whether or not the monitor has sharing turned on. Outlook shows them without asking to download pictures.
• A daily summary worth reading. On a quiet day the daily summary was the same email as the day before. It now gives a line for each monitor: how many checks it made, what passed, failed or changed, when it last checked and how long its checks took, each set against the 24 hours before. The subject line says how the day went, and sections with nothing in them are left out.

We now advertise on Google, and the privacy policy, effective today, says how we measure those ads.

• Only with your consent. Google Ads sets its cookies only if you accept marketing cookies in the consent banner. Without that, it receives signals without cookies that it uses to estimate, in aggregate, how many sign-ups our ads brought.
• Measurement, nothing more. Ad personalisation and Google Signals are off, so what Google Ads learns on our site is not used to show you ads elsewhere or to build audiences of our visitors.
• The public website only. As with Google Analytics, nothing from the signed-in app reaches Google Ads.
• Change your mind at any time from Cookie settings in the website footer.

A few things said more than they meant, or less.

• Change summaries leave out what ticks. A summary quoted the whole watched spot before and after, countdown included: "held for 23:05:24", then "23:05:04". It now quotes only the sentences that changed, and shows a clock or countdown left in them as "…". The diff picture no longer marks a countdown's digits either.
• Shared reports give the site's time. A shared report gave the time of the check in UTC, hours away from what the app showed, without naming a zone. It now uses the site's time zone and names it, such as "8:53 PM EDT". It also gives how long the check took the way the app does, such as "24.2 sec".
• The Share dialog's button stays in view. With a full summary in the preview, "Create share link" started below the bottom of a laptop screen. It now stays at the foot of the dialog while the rest scrolls.
• Dashboard charts say which days they count. The Failures tile counts 30 days, and the Changes / Failures chart counts the range picked on Check Volume, 7 days unless you change it. The two could disagree with nothing to say why. Each chart now names its window, and long axis numbers are shortened ("1.2k") instead of being cut off.
• Plainer monitor labels. Change monitors show their preset as Balanced, Fast or Focused. They no longer carry labels about how they're analyzed or what that costs, which meant nothing to anyone outside Simrix Monitor.

A price going from $49 to $59 changes a digit, and on a spot the size of a plan card that is very few pixels. The monitor saw the change in the words and reported it, but kept the marked-up picture only when enough of the picture had changed by itself, so the change usually came without one.

• The picture comes with the change. When a change monitor finds a change in the words it watches, it now keeps the picture that marks where on the page it is, even when only a digit moved.
• One full stop. When the text a check looks for is a sentence of its own, like "Thanks, your request is in.", the failure summary no longer adds a second full stop after it.

Alerts reached Slack only through a relay you built yourself. Slack now has its own integration.

• Add to Slack. Open Integrations, choose Add to Slack and pick the channel in Slack. Simrix Monitor asks for one permission, to post in that channel, and nothing else.
• The evidence, in the channel. A failure arrives as the email does: Failed at step 4 of 6: The payment form appears, the reason in plain English, what likely happened, and buttons to the check and its shareable report.
• Recoveries and changes. A recovery says how long the monitor was failing. A change monitor posts when the page changes, with the summary.
• Pictures when you choose them. Include the screenshot adds the picture of the failed step, for monitors that include a shareable report link in alerts.
• How it went. Each channel's card shows how its last message went, and Send test message checks it on demand.

Slack is included in the paid plans, alongside webhooks and the API.

A few things on screen said less, or worked less well, than they should have.

• No more "Unknown" badges. Every monitor card, check row and site card showed a badge for whether it could be checked, and almost always it read "Unknown" or "Allowed", which tells you nothing you can act on. It now shows only when a site is flagged or blocked, the same as on a check's own page.
• 100% means every check passed. A month with 12,836 passing checks and 19 failures showed a success rate of 100% beside those 19 failures. Rates near the ends now keep one decimal, so that reads 99.8%, and any failures always show at least 0.1%.
• "Side by side". The switch between a change's before-and-after views read "Side By-Side". It now reads "Side by side", "Slider" and "Diff".
• One press makes a share link. The first press of "Create share link" often did nothing: leaving the title field rebuilt the preview, which moved the button out from under the pointer. The preview now stays put while it updates, and is not rebuilt when the title has not changed.

WooCommerce's own product page answers Add to cart by coming back with a message: the product "has been added to your cart", with a View cart link. Guided setup took that message for the cart, looked beside it for Proceed to checkout, and stopped, saying it could not find one.

• Into the cart first. When Shoppers can buy goes on to the checkout, it now opens the cart the way a shopper would, by your store's own link to it, and presses Proceed to checkout there.
• The monitor does the same. The monitor it saves opens the cart on every check before going on to the payment form.
• The free check is unchanged. The free Checkout Health Check stops at the cart, and still takes that message as the cart.

A check that already has a share link lists it in the Share dialog, under "Existing links". An alert with a share link in it makes one.

• The button stays in the dialog. A long link made the dialog's contents wider than the dialog itself. "Create share link" sat past its right edge, out of sight, and a press where it should have been closed the dialog.
• Long links are shortened. The contents now keep to the dialog's width, and a long link in the list ends with an ellipsis. The link you just made is still shown in full, ready to copy.

A failure alert used to open with a severity and an explanation, and said nothing of where the check had stopped: it never knew which step failed. It now leads with the evidence.

• The step that failed, first. Failed at step 4 of 5: Press Proceed to checkout, then why, in plain English. The subject line names the step too, and the page element the step was looking for is no longer shown.
• A picture of that step. When the monitor includes a shareable report link, the alert shows the screenshot of the step that failed, and the link opens the full report.
• One explanation. What likely happened, the likely impact and what to check first are written once for each failed check and kept, so the alert and the check page say the same thing.
• The shareable link, as you set up. Include a shareable report link in alerts is on the confirm screen of guided setup and in a monitor's settings. A link an alert carries stops working after 30 days.
• How long it was down. A recovery email says how long the monitor was failing and across how many checks.
• Change monitors too. A change monitor that cannot capture its page sends the same kind of alert, with the same link and explanation.

Webhook deliveries for a failed check now include the step it stopped at, as failedStep.

A failed check used to show where it stopped: one screenshot and a sentence. What led there, such as whether the item reached the cart or which page the check was on when the button went missing, had to be worked out from that one picture. Every check now keeps a screenshot of each step as it finishes.

• Every step, in order. The check page lists each step, whether it passed and how long it took. A failing check opens on the step that failed, marked Failed here with the reason beside it, and the steps after it are marked Not reached.
• Look at any step. Click a step, use the arrows or the slider, or press the left and right arrow keys to move through them. Click the picture to open it at full size.
• Named in plain words. Each step is named by what it does, like Press Add to cart, in the same words the alert uses.
• Kept like every other screenshot. Step screenshots are kept for as long as a check's other screenshots and are deleted with your account.

Checks from before today keep their single screenshot.

Setting up a monitor used to mean choosing a template, finding the right buttons on your page and saying what the final check should look for. Most people know what matters to their business, not which element on the page proves it, so guided setup asks for the first and works out the rest.

• Choose what to protect. Shoppers can buy, search finds products, a page is up and says the right thing, or tell me when a page changes. Not sure which? Describe it in your own words.
• Answer only what you know. Which product to use, or let us pick one. The word a customer would search for. The words a page should show. Alerts go to the site's notification email, filled in for you.
• Watch it being set up. A real browser does what a visitor would, step by step, with a screenshot of each. A product that wants a size, colour or quantity gets one chosen, as a shopper would, and the monitor makes the same choices on every check.
• Save only what passed. Before anything is saved, the monitor is checked once exactly as it will be every time after. Its first check starts as soon as you save it.
• When a step can't be done, you hear why. Try again, use a different product or word, or Pick visually to show us the button yourself.

Advanced setup is still there for developers and agencies, behind its own button. Its sections now say which parts are done and which are still needed, and a list beside Create Monitor names anything missing.

A store's cart can be fine while nobody can pay. The page that matters most is the checkout's payment form, and a monitor that stopped at the cart never saw it. Monitors set up with Shoppers can buy now go on to it.

• On to the payment form. After the cart, the check presses your store's own Proceed to checkout and looks for the payment form, the way a shopper would see it. It never types into your checkout and never presses anything that places an order or takes a payment.
• Honest about stores that ask first. Some checkouts ask for contact and delivery details before they show any payment form. For those, the monitor checks that the checkout opens, and setup says so rather than claiming more.
• Ways on when the checkout will not open. Show us the Proceed to checkout button and we add the product to the cart first so it is there to pick, or Stop at the cart and check that shoppers can add to it.
• Every step named. Each step is named in plain words, like Press Add to cart or The payment form appears, and those are the words an alert uses when one fails.
• Add your site right there. With no site yet, guided setup asks for its address and carries on. Add another site sits beside the site list for when you have one.

Monitors you already have are unchanged. To move one on to the payment form, set it up again with Shoppers can buy.

Every check starts as a new visitor, and a new visitor's cart is empty. A monitor that opened the cart page and looked for the checkout button failed on every store that hides the button until something is added, and its alert said only that the button was missing, which reads as a broken checkout. Checking a cart needed two pages in one visit, and the setup form could only describe one.

• Then open this page. A guided click journey can open a second page on the same site after its click, before the final check. Start on a product page, press Add to cart, open /cart, and check for the checkout button. The check waits for the store to answer the press before it opens the cart, so the item is there when it looks. Monitors made from the free Checkout Health Check already worked this way, and editing one now keeps its cart page instead of dropping it.
• The picker follows the journey. The final check of a guided click journey can be picked visually, and the picker presses the button and opens the second page first, so the checkout button is picked from a cart with something in it rather than from an empty one.
• An empty cart is named. When a check fails on a cart page that says it is empty, the result and the alert say the cart was empty and how to set the monitor up to fill it first.
• A template's built-in wait no longer fails a check on its own. Some templates also wait for a common page element after the click, which the setup form does not show. On a store without that element the check failed before your final check was looked at. The wait is now a hint, and your final check decides. Editing and saving an older monitor applies this to it too.

Nothing changes for customers: alerts still arrive by email or by webhook, which can pass them on to a chat tool, and we still send no marketing by text message.

• The privacy policy, effective today, spells out the program in its marketing section: who receives the messages, what we collect for them, how it is used, that message frequency varies and message and data rates may apply, how to stop, and that mobile numbers and messaging consent data are never shared, sold or provided to third parties or affiliates for marketing.
• A public page, Text message notifications, describes the program: who receives the messages, how a person opts in and out, and what the messages say.

On a store whose product page opens under a consent dialog, the free Checkout Health Check found the add-to-cart button, saw it enabled, pressed, and got nothing, because the dialog took the press. It reported a button that did not respond, on a store where every shopper simply clicks "Allow all".

• The free check clears what a shopper would clear. A cookie banner or pop-up over the button is accepted or closed, and the button is pressed again, the same way a workflow monitor's click step already worked.
• A button that truly does nothing is still reported as that. The retry happens only when something covered the button; a press that lands and adds nothing reads as before.

On a store whose homepage carried a reviews plugin, the free Checkout Health Check read the plugin's "Homepage" product block as the page describing itself as a product, started from the homepage, pressed a product tile's button, and reported that the button did not respond. The store had a dozen product links on that page.

• The homepage is judged last. The check follows the homepage's product links, the Shop link, the categories and the sitemap first, and treats the homepage as the product only when nothing it links to is one.
• A product block with no address does not make a homepage a product. On a product page that block is the page's own markup; on a homepage it is a widget's. Structured data now makes a homepage the product only when it names the homepage itself.
• A store whose homepage is its one product still works, on the strength of a price beside its add-to-cart button, as before.

A store that challenges suspected automation turned checks away, and from the alert it looked like the store was down. Monitors browsed as an ordinary Chrome browser with nothing for a protection service to allow.

• Monitors, setup previews and the homepage scan carry SimrixMonitor/1.0 in their browser name, with a link to the docs page that explains it.
• One rule covers every visit. The free Checkout Health Check carries the same name; allow a browser name containing SimrixMonitor/1.0 and every visit gets through.
• The site form says so where you enter your address, and the troubleshooting docs show where the rule goes.

When you delete your workspace, the app removes the workspace, everything in it, and the sign-ins of members who belong nowhere else. Those two things happened one after the other, with the removal of stored screenshots in between, and a browser still open on the app could ask for the account in that gap. The app treated a sign-in with no workspace as a brand-new customer and gave it a fresh, empty workspace, so a deletion could end with the account still there under a new name.

• The workspace and its members' sign-ins are removed in one step. There is no longer a moment in which a sign-in exists without a workspace, so nothing can hand it a new one.
• If any part of the deletion fails, nothing is deleted. The page tells you so, and you can try again.
• Members who also belong to another workspace keep their sign-in, as before, and nothing of that other workspace changes.

The Terms of Service were written before the free Checkout Health Check existed and before the Privacy Policy said, in detail, how long we keep what we capture. The three documents now say the same things.

• A Data Processing Agreement. Personal data can appear in a page you monitor, such as a name on an order confirmation. The new agreement at /dpa sets out our role as your processor: what we do with that data, who our subprocessors are, how we secure it, when we tell you about a breach, and how it is deleted or returned.
• The free tools are covered. Running the Checkout Health Check against a store means agreeing to the same rules as a monitor: the store is yours, or you are allowed to test it.
• Deletion says what it does. Deleting a workspace is immediate; screenshots and page text follow the retention period in the Privacy Policy; and the Terms say how long we keep data if we end an account ourselves.
• The version you agreed to is recorded. The Terms carry a new effective date, and every new account records which version it accepted.

The public website sets one first-party cookie of its own, to record which campaign or referring site brought a visitor here, so that sign-ups can be attributed to the channels that earned them. A consent banner can hold back scripts until you decide, but not a cookie the server sets, and this one was being set before the banner had been answered.

• It now waits for your answer. Where the consent banner is shown, the attribution cookie is written only once you have allowed statistics cookies.
• Declining means never. If you decline, or your browser sends the Global Privacy Control signal, it is not set.
• Nothing else changed. The cookies that keep you signed in, protect forms and remember a plan you picked are unaffected.

The policy still says exactly what the product does, section by section, and it now says more of it.

• Cookies and consent. The categories we use, what the consent banner lets you choose, how to change your choice, and that we treat the Global Privacy Control signal as a refusal.
• Your rights, by region. The GDPR rights by article, and the rights of residents of New Jersey, California and other states with privacy laws, with how to submit a request and how to appeal.
• Where data lives. Our servers are in the United States, and the mechanisms we rely on when data leaves Europe.
• Marketing. Opt-in where the law requires it, an unsubscribe link in every marketing email, and no marketing by text or telephone.

Creating an account has always meant agreeing to the Terms of Service and Privacy Policy, and the sign-up page said so, below the form, where a person who had just pressed the button might not have looked.

• Above the button, not below the form. The sentence now sits immediately above "Continue with Google" and immediately above "Create account", so it is read before the press it applies to. The sign-in page says the same above its Google button, because a first Google sign-in creates an account too.
• Your account keeps the record. When you create an account, it records the moment and which Terms were in force, by the effective date shown on the Terms page. Nothing is recorded for accounts created before this change.

Between 06:57 and 11:16 UTC this morning no scheduled checks ran and no alerts went out. One check had stalled inside the browser, on a page whose script never finished, and the service waited for it rather than moving on. It was restarted by hand.

Three changes make sure that cannot happen again.

• Every check has a hard time limit. A check that has not finished within it is stopped, the browser is closed by force, and the check is recorded as "did not finish within its time limit". The next scheduled check runs as normal.
• The check service restarts itself. If it ever stops making progress for ten minutes, it exits and comes back within a minute.
• The health endpoint can say when checks have stopped. An outside probe can now ask for that and be answered with an error, so a stall raises an alarm instead of waiting to be noticed.

The four "failed" alerts sent between 06:57 and 06:59 were caused by the stall, not by the sites; every one of those pages passed on the next check.

A workflow monitor judged its success condition the instant its last step finished, after a short pause of about two seconds. On a slow store the answer to a press, the "added to your cart" notice, the new address or the confirmation, arrived after that, and the check read it as missing. Nothing was wrong on the site; the check was early.

• Checks keep looking for what they were told to expect (text, a title, an address or an element) for up to fifteen seconds after the last step, inside the check's existing time limit.
• A passing check is as fast as before. A condition already met returns at once.
• A failing check waits those seconds first, and its screenshot shows the page as it was at the end of the wait, so the picture is of the answer that did not come rather than of a page still loading.
• Conditions about something being absent are judged once, as before. A page still settling would make them true for the wrong reason.

Four changes to change monitors, all from watching them run against pages built to trip them.

• Clocks, countdowns and visitor counts no longer count as changes. "Updated 12 minutes ago", "Sale ends in 02:59:41" and "27 people viewing" tick on every visit. They are set aside before the comparison, so a check that saw only those move stays quiet. A price, a percentage and an "only 3 left" still count.
• A spot that moved is not a spot that changed. When an announcement bar pushes the page down, or a scrollbar shifts it half a pixel, the words are the same but every letter's edge was drawn slightly differently. The comparison is now forgiving of that and still catches a changed digit, a badge, a strikethrough or a colour change.
• A blocked page says so. When a page answers a check with an error, such as HTTP 403 or 429, the check reports that the page returned an error, rather than that the thing it watches was missing.
• The picker looks twice. After you pick a spot, it is checked again a few seconds later. If it changed on its own in that time, the way a slideshow or a rotating offer does, the picker says so before you save, because a monitor on a spot like that would alert on every check.

A florist's store showed us the gap. Its roses need a colour and a quantity chosen before add to cart, and pressing the button without choosing brings up "please select some product options" and adds nothing. The free check then opened the cart page, saw the word "cart" in its address, and reported a working checkout path. The monitor created from that result expected the address to change after the press, which it never does on that store, so it alerted at every check on a site where nothing was wrong.

Three things change.

• A cart page counts only when it shows something in it. The check reads the cart's own words, a subtotal or "proceed to checkout", and a page that says the cart is empty is never evidence, whatever its address.
• A product that asks for a choice in a dialog is read as needing a choice. WooCommerce's option pickers are recognised too, so such a product is reported as a step the check could not take, like a store with a "Select a size" button already was.
• A monitor made from a free check repeats what the press really did. When the check reached the cart by following a link or opening its address, the monitor opens that page after the press too, in the same visit, and checks for the cart's contents rather than for an address.

If you have a monitor named "Add to cart" that was created from a free check and has failed on every check since, it is one of these. Deleting it and running the free check again gives you a monitor that watches what the store actually does.

The free Checkout Health Check reports what one visit could confirm, and on three kinds of store it was claiming more than that.

• A product that needs a size or colour first. The check pressed add to cart without choosing one, nothing was added, and the empty cart was reported as a checkout path that stopped. A product that wants a choice first is now a step the check could not take, said in those words, whether the button was disabled, read "Select a size", or accepted the press and added nothing.
• A product or cart page behind bot protection. A page that turned the check's browser away, or showed a "verify you are human" page instead of the product, was reported as a broken page. It is now reported as bot protection, which shoppers never see and this check cannot get past.
• The cart page it names. When no cart page showed the item, the report named the last address the check had guessed at, often a page the store never links to. It now names, and photographs, the store's own cart page that loaded.

None of this changes what a clean pass means: every step still has to be confirmed before the check says the path worked.

Simrix Monitor is live. This is what it does today.

• Workflow monitors drive a real browser through the journeys that decide whether you get paid: checkout, login, signup, forms and key pages. You build them from templates, with no code.
• Change monitors watch any public page, your own or a competitor's, and tell you when it really changes, with a before and after, the text that moved and a highlighted visual diff.
• Every alert carries the evidence: the screenshot, the step that failed and a plain-English summary of what went wrong. Alerts go by email and signed webhook, and a weekly digest sums up what ran and what broke.
• Shareable evidence reports give a client or a colleague a link to one check, or an ongoing link to one site, without an account.
• A free Checkout Health Check walks a store from its homepage to a cart with an item in it and shows a screenshot of every step. No account needed.
• MonitorBot, the built-in assistant, answers from the documentation and from your own monitors and recent checks.
• Plans are three numbers: monitors, how often they check, and sites. See pricing.