The Shopify Outage of July 10, 2026, Seen From an Independent Pixel

01 / The short answerThe dashboard said zero. The store was alive.

On July 10, 2026, Shopify reported degraded performance on storefronts and admins for roughly an hour around midday Eastern time. During that window, a merchant we measure asked an AI assistant, connected to his Shopify data, why revenue was so low. The assistant reported zero tracked add-to-carts and near-zero cart activity, and recommended a crisis response.

The independent pixel running on the same store recorded sessions in every single hour of the day, between 4 and 45 per hour. The store finished the day with 25 add-to-carts, and 19 of them arrived after 19:00 UTC, within a few hours of Shopify declaring the incident resolved. The peak hour, 20:00 UTC, produced 9 add-to-carts on its own.

The point of this write-up is not that Shopify broke. Platforms break; this one recovered in under an hour. The point is what a single-source dashboard does to a merchant's judgment while the platform is the thing that is degraded, and what the same day looks like when a second, independent instrument is watching.

02 / The recordThe outage, per Shopify

Shopify's own status page (shopifystatus.com) documents the incident cleanly. All times below are as Shopify published them, in Eastern time, with the UTC equivalent alongside since the rest of this article works in UTC.

The affected components were listed as Admin and Storefront, both at Degraded Performance. Note the word choice: degraded, intermittent. Not down. Some requests failed, most did not. That distinction matters for everything that follows, because a degraded platform produces exactly the kind of partial, confusing data that a dashboard renders as a clean and terrifying zero.

From first investigation to resolution the window ran 55 minutes. By Shopify's standards and anyone else's, that is a fast recovery.

03 / The scareWhat the dashboard said at noon

The store in question is an off-road parts store on Shopify, doing roughly 300 sessions a day. We are not naming it; the details that matter are the numbers, and they are the same numbers any mid-size store would have seen.

Around midday, with the incident in progress, the merchant asked an AI assistant that reads his Shopify data why revenue looked so low. The assistant answered with what the platform showed it: zero tracked add-to-carts and near-zero cart activity for the day so far. It then did what any competent assistant does with an input like that. It assumed the store was broken and produced a full crisis checklist: check the theme, check the apps, check the payment gateway, consider rolling back recent changes.

None of that was wrong given its inputs. The assistant reasoned correctly from a single source. The single source was the problem, because at that moment the source itself was the degraded system.

04 / The measurementWhat the pixel recorded, hour by hour

Harvv's pixel runs in the shopper's browser, first-party to the page, and does not depend on Shopify's ingestion pipeline. Here is the full July 10 record for this store, in UTC. The highlighted rows span the Shopify outage window, 16:24 to 17:19 UTC.

Three things stand out.

Sessions never stopped. Every hour of the day had traffic, including both outage-window hours (25 and 22 sessions). "Degraded" meant some requests failed intermittently, not that the storefront went dark. Shoppers were on the site the whole time.

The add-to-cart drought was long, and mostly not the outage. Zero add-to-carts from 04:00 through 16:00 UTC. The outage did not start until 16:24. Most of that drought is simply what overnight and morning look like for this store, which we return to below.

The recovery was fast and sharp. The evening burst from 19:00 to 22:00 UTC delivered 19 of the day's 25 add-to-carts, with 9 in the 20:00 hour alone. Within a couple of hours of Shopify declaring the incident resolved, this store had its best add-to-cart hour of the day. Whatever buying intent existed did not evaporate. It arrived on schedule with the evening traffic.

05 / The honest partWhat the zero actually was

It would be convenient to write "the dashboard said zero, the pixel said everything was fine," and stop there. That is not what the data shows, and the difference is the most useful part of this story.

The midday add-to-cart drought was real in both systems. Harvv also recorded approximately zero add-to-carts from 04:00 to 16:00 UTC. The dashboard was not hallucinating a quiet morning; the morning was quiet. Overnight and morning are normally low-intent hours for this store, whose buyers skew toward evening browsing. The outage landed at the tail of a normal quiet stretch, which made a routine pattern look like a catastrophe in progress.

So the dashboard's "zero" at midday was three things layered on top of each other:

1. A normal slow morning. This store frequently posts hours of zero add-to-carts before its evening rush. On a day without an outage, nobody asks the dashboard about it.
2. A day-window artifact. "Today" in a dashboard is a timezone-bound window. Depending on where the day boundary falls, the small overnight cluster of add-to-carts (five of them between 01:00 and 03:00 UTC) can fall inside or outside the window the merchant is looking at. A zero can be partly an accounting boundary, not a behavior.
3. The outage. Real, but only 55 minutes of a 12-hour drought, and sitting at the very end of it.

This is worth being precise about because the tempting version of this story, "the platform lied and we caught it," is false. The platform showed a real quiet period through a degraded lens at the worst possible moment. The independent pixel did not contradict the quiet; it contradicted the conclusion.

06 / The structural findingThe chronic telemetry gap

There is a second finding in the July 10 data, and it requires the same discipline: we are not going to attribute it to the outage, because the data says we cannot.

The pixel observes failed network requests from real shopper browsers. On July 10, requests to Shopify's own browser-side telemetry endpoints (monorail-edge.shopifysvc.com and its OTLP metrics path) failed 317 times across the day. Here is the part that matters: those failures did not cluster in the outage window. They tracked traffic, running all day and peaking at 54 failures in the 19:00 UTC hour, the start of the evening rush, well after the incident was resolved.

That is not an outage signature. That is a chronic failure rate: on an ordinary day, some fraction of shopper activity on this store never reaches Shopify's collection pipeline at all. The outage did not create this gap. The outage was just the day we happened to be looking closely enough to notice it.

The same day's log shows /cart.js failing 65 times, spread across the day rather than clustered at the outage. Readers of our earlier work will recognize that pattern: it is the silent cart-breakage failure mode we documented across four stores in the Shopify friction tax. Cart endpoints fail quietly at a background rate on normal days, and no dashboard reports it, because the thing that would report it is the thing failing.

Neither of these numbers is an accusation. Browser-side telemetry fails for many reasons: ad blockers, privacy extensions, flaky mobile networks, tab closes mid-request. Some of the 317 are certainly that. But whatever the mix, the operational conclusion is identical: the platform dashboard's picture of shopper behavior is systematically incomplete, by an amount the platform itself cannot see, on days with no outage at all.

07 / ApplicationWhat this teaches

Three things worth keeping from July 10, none of which require a villain.

1. When a platform is degraded, its own analytics are least trustworthy exactly when you need them most. The moment you most want to know "is my store working?" is the moment the instrument answering that question is the impaired system. Any measurement chain that runs entirely through the thing being measured fails in the same direction, and it fails toward panic.
2. "Zero in the dashboard" is not "zero in the store." Independent measurement showed sessions in every hour of the day and buying intent returning within hours of resolution. A zero deserves the same skepticism as any other extreme reading: it is a claim by one instrument, not a fact about the store.
3. An AI assistant is only as good as the data sources it can reach. The assistant that recommended crisis mode was not malfunctioning. It reasoned soundly from the one source it had. Give the same assistant a second, independent source and the answer changes from "your store is broken" to "your platform had a 55-minute incident during your normal quiet hours, and your evening looks fine." As merchants wire assistants into their operations, the quality of the answer is decided by the plumbing, not the model.

08 / MethodHow we measured this

Everything above comes from Harvv's behavioral pixel running on the store in question, plus Shopify's public status page for the incident timeline.

The pixel carries zero personal data by design. Everything in this article is counts and timestamps.

09 / HonestyLimitations

This is one store, on one day, observed rather than experimented on. The absolute numbers are small: 25 add-to-carts is a normal day for a store this size, and single-hour counts of 1 to 9 events should be read as a shape, not a precise rate. The hourly rollup is in UTC while the merchant's dashboard renders a store-local day, so the two systems' "today" windows genuinely differ, and part of the midday discrepancy lives in that boundary. We cannot decompose the 317 failed telemetry requests into their causes (ad blockers, network conditions, and platform-side errors all contribute), which is exactly why we do not attribute them to the outage. And a fast, well-handled 55-minute incident on one afternoon says nothing general about Shopify's reliability, which was not the subject here. The subject was what a single instrument does to judgment, and one day was enough to show that.