1. Adding a Store

Paste a Shopify domain — yourstore.myshopify.com or a custom domain like yourstore.com. That's it. We don't need your Shopify credentials, we don't install an app on the store, and your client never needs to know a monitoring tool has been set up.

We resolve the domain to its canonical Shopify storefront URL on the first check, following any redirects so monitoring stays accurate even if a store switches from a .myshopify.com URL to a custom domain.

After the first three successful checks we establish baselines for speed scoring and structural hashing. From that point on, you're fully monitored.

2. The Check Cycle

Every check runs the same sequence of steps for each store. On your plan's interval — every 5 minutes on Pro and Agency, every 15 minutes on Free.

3. Checkout Probing

This is the part most monitoring tools skip. A generic uptime checker confirms the storefront returned HTTP 200. That's not enough — a store can load fine while its checkout is completely broken.

We probe checkout in three steps:

4. Theme Change Detection

Every check generates a structural hash of the storefront — a SHA-256 fingerprint of the page's layout, sections, installed apps, and tracking pixels. When the hash changes, something meaningful changed about the store.

What goes into the hash

We deliberately include signals that matter for store health and exclude signals that create noise:

A/B test filtering

A naive hash comparison would fire alerts for every A/B test. We use a stability window: a new hash must appear on two consecutive checks before we treat it as a genuine change and fire a STOREFRONT CHANGED event. A hash that appears once and then reverts is silently discarded as a transient variation.

At 5-minute check intervals, this means a theme change is confirmed in around 10 minutes. At 15-minute intervals it's around 30 minutes — a trade-off of speed versus noise on the Free plan.

5. Speed Monitoring

Raw response times are noisy — network conditions vary, servers have spikes, CDNs have bad days. We use a relative baseline approach so alerts fire on meaningful degradation, not momentary blips.

Baseline establishment

The first three successful checks with valid response times are averaged to form the store's speed baseline. This baseline is stored and updated only by adding new successful checks into a rolling average — it won't drift from a single slow check.

Speed scoring

We convert response time to a 0–100 score on a Lighthouse-style curve. Faster stores score higher. The exact score matters less than the change in score.

Alert threshold

A SPEED DEGRADED alert fires when the current speed score drops 40 or more points below the baseline. Examples:

The relative threshold means a naturally slow store (baseline 30) won't spam alerts just because it's slow. And a fast store (baseline 90) gets alerted when it drops to 50, which would be invisible to an absolute threshold set at "alert below 40."

6. SSL & Password Monitoring

SSL certificate monitoring

We check the TLS certificate on every monitoring cycle. We verify it's currently valid and read its expiry date. Two alerts are generated automatically:

• SSL EXPIRING SOON — 14 days before expiry
• SSL EXPIRING CRITICAL — 3 days before expiry

An expired certificate puts a red padlock warning in every visitor's browser. For a client's store, this is often a more urgent problem than downtime — it actively destroys conversion.

Password protection detection

We detect password-protected stores by checking for Shopify's password template signals — the template-password body class, /password form actions, and related DOM markers. When detected:

• A STORE PASSWORD PROTECTED alert fires
• Checkout probing is skipped (checkout is definitionally unavailable)
• Health status is set to DEGRADED

Agencies accidentally putting client stores into password mode (during theme work, for instance) is a surprisingly common and embarrassing incident. This catches it in the next check cycle.

7. Alert Logic

State-change only

The most important design decision in Radar Monitor is that alerts only fire on state transitions — not on every failed check. If a store is down for an hour, you get one alert when it goes down and one when it recovers. Not 12 alerts in the meantime.

Consecutive failure threshold

A single failed check doesn't trigger an alert. We require two consecutive failures before firing a STORE UNREACHABLE event. This eliminates false alarms from transient network conditions, CDN hiccups, and our own infrastructure variability.

On a 5-minute check interval, this means you might not hear about a genuine outage for up to 10 minutes after it starts. On the Free plan's 15-minute interval, that extends to up to 30 minutes. That's the deliberate trade-off for eliminating false positives. One false alarm at 3am trains teams to ignore future alerts. We'd rather be slightly slower and always trustworthy.

What alert emails look like

Here are real examples of what arrives in your inbox:

↑ Outage alert. Sent once on first confirmed failure.

↑ Recovery alert. Sent on first successful check after outage.

Alert types

8. What We Don't Do

• We don't create orders. Adding to cart is not placing an order. No inventory is reserved, no customer record is created, nothing appears in the Shopify admin.
• We don't access the Shopify admin. Everything we do is via public storefront URLs. No admin API, no Partner dashboard, no credentials required.
• We don't scrape product data, pricing, or customer information. We pull the minimum needed to probe checkout — one product variant ID — and nothing else.
• We don't store page HTML. Snapshots store derived metrics (hashes, scores, status codes) — not the raw page content.
• We don't alert on every check. Only state changes generate alerts. A store that has been down for 6 hours has generated exactly one alert — the initial STORE UNREACHABLE event.
• We don't ignore robots.txt. If a store's robots.txt disallows RadarMonitorBot, we stop monitoring it and notify the account holder. See our bot transparency page.

9. FAQ