Uptime monitoring is table stakes and, for a Shopify store, mostly answers a question Shopify already answers for you. The platform’s availability is on its status page. The failures that actually reach a merchant are changes: a theme published on Friday, an app installed by a contractor, a domain setting altered during a migration. None of them produce a downtime alert. All of them are visible in the public storefront if something is looking.
In short
- A 200 OK tells you the server answered. It says nothing about indexability, canonicals, or whether add to cart works.
- Most storefront regressions are configuration or theme changes, and they surface first in the public HTML.
- Watch a small set of signals at a sensible cadence, compare against a baseline, and treat changes as prompts, not verdicts.
- Browser-level checks and field vitals still need a browser; no server-side observation replaces them.
Uptime answers one question
An uptime check asks whether a URL returned a successful status inside a timeout. That is worth knowing, and on Shopify it is rarely the problem. The storefront is served from Shopify’s infrastructure; when it is down, everyone’s store is down, and the status page says so before any third-party monitor does.
What is specific to your store is everything layered on top: the theme, the apps, the domain and redirect configuration, the SEO settings, the scripts every page loads. Those change constantly, usually by well-intentioned people, and the platform will happily serve a 200 for a homepage that has just become invisible to search engines.
The failures a 200 can hide
These are the ones that come up repeatedly. Each is a real change in the public response, and each has been discovered weeks late by a merchant looking at a traffic chart.
- An unintended noindex. A theme copy used for preview carried a robots meta tag; someone published it. Search engines obey it within days. The store stays up the entire time.
- Canonical drift. After a market or domain change, the homepage canonical points at a locale path, the
myshopify.comhost, or a URL with a tracking parameter. Rankings consolidate onto the wrong URL. - A new redirect hop. A DNS or proxy change adds a redirect in front of Shopify’s own. Nothing breaks. Every first visit gets slower, and crawlers see a chain.
- A title that quietly changed. An SEO app rewrote it, a theme update reset it, or a placeholder from a page builder shipped. Click-through drops without any error anywhere.
- The password page. Enabled to preview something, forgotten for a weekend. Every visitor sees it. Every request returns a success code.
- A script footprint jump. Three new third-party hosts appear after an app trial. The trial ends; the embed stays on. The page got heavier and no one was told.
- Broken purchasing. A theme edit throws a JavaScript error and the add to cart button stops responding. The page loads, looks perfect, and sells nothing. This one needs a browser to catch, and it belongs on any post-publish checklist.
What to watch, and how often
The list below is deliberately short. Every signal is something a change would move, and every cadence reflects how quickly that change starts costing money. Public signals can be observed by a server without a browser; the last two rows cannot.
| Signal | What it catches | Evidence | Cadence |
|---|---|---|---|
| Final URL and status code | Redirect loops, a new hop after a domain change, a 5xx behind a proxy | Public | Hourly to daily |
| Robots meta and X-Robots-Tag | A noindex shipped with a theme publish or left over from a password period | Public | Daily |
| Canonical URL | Canonical drift to a locale path, a myshopify.com host, or a parameter URL | Public | Daily |
| Title tag | SEO app changes, theme publish regressions, accidental placeholder titles | Public | Daily |
| HTML size and stable content hash | Sections added or removed, large inline payloads, unexpected theme edits | Public | Daily |
| Script count and third-party hosts | New app embeds, vendor swaps that were never finished, injected tags | Public | Weekly |
| Time to first byte trend | Sustained drift after a proxy, CDN or app change; not a one-off spike | Public | Daily, read weekly |
| robots.txt and sitemap.xml | A Disallow added by hand, a sitemap still on the old host | Public | Weekly |
| Add to cart, cart drawer, checkout entry | A JavaScript error from a theme or app change that breaks purchasing | Browser | After every theme publish |
| Core Web Vitals field data | Real-device regressions over 28-day windows | Browser | Monthly |
The public rows in this table are what Store Monitor records for each run: status, final URL, title, canonical, indexability, response size and a stable content hash.
How to read a change
A monitor that alerts on every difference gets muted within a week. The useful discipline is to sort changes into three kinds before deciding whether anyone needs to be woken up.
Availability changes
Status moved out of the 2xx range, the request timed out, or the final URL changed host. These are urgent by default. Confirm from a second location or a phone on mobile data before escalating, because a single failed request from one network is not an outage.
Indexability changes
A robots meta or header appeared, the canonical moved, or robots.txt gained a rule. Urgent within the day. The cost accrues silently and reverses slowly, so the question is not whether the store is up but whether someone meant to do this.
Content drift
The title, the HTML size or the content hash changed. Often expected: a theme publish, a new homepage section, a seasonal banner. The right response is to look, note what changed and by whom, and move on if it was intended. The value is the record, not the alarm.
Avoiding false alarms
Compare the HTML with scripts and styles removed, otherwise per-request nonces, session identifiers and inline app state will report a change on every run. Expect the first observation after any theme publish to differ, and treat A/B tests and personalization as known sources of drift. A change is a prompt to look, not a diagnosis.
A monitoring routine without a tool
None of this requires software. It requires someone doing the same thing on the same day every week and writing it down. A workable manual version:
- Capture a baseline once: final URL, status, title, canonical, robots directives, HTML size, script count, third-party hosts, and the first lines of
robots.txtandsitemap.xml. Store it somewhere the team can see. - Weekly, fetch the homepage, one collection and one product page, and compare each field against the baseline. Fifteen minutes with a browser’s view-source is enough.
- After every theme publish, walk the purchase path in a browser: product page, add to cart, cart, checkout entry, account login. Watch the console for errors.
- Monthly, read the Core Web Vitals report in Search Console and the coverage report for new exclusions.
- Any time something differs, record who changed it and why before deciding whether to revert. A change log is the most valuable output of the whole routine.
The trouble with the manual routine is not that it is hard. It is that it stops the first busy week, and the regressions it would have caught tend to arrive during busy weeks.
What Store Monitor covers
Store Monitor automates the public rows of the table above for stores in a TechBits workspace. Each run records availability, HTTP status, time to first byte, the final URL after redirects, the title, the canonical, any robots noindex directive, the response size, and a stable hash of the HTML with scripts and styles removed. Runs are compared with the previous observation and produce change events across availability, HTTP status, title, canonical, indexability and content. Intervals are configurable between one hour and one week per monitor.
It is not browser monitoring: it does not load JavaScript, exercise add to cart, complete a checkout, or measure Core Web Vitals. It is not an uptime service with a contractual SLA. Monitor history is written server-side and cannot be edited from the workspace. Runs are executed by a scheduler on the hosting side, and each monitor shows when its last observation was actually taken, so a quiet monitor is distinguishable from an idle one. Continuous monitoring is only active once that scheduler has been configured and verified; TechBits does not describe monitoring as running when it is not.