Eighteen days later, Boost Commerce merchants still deserve answers

On October 18, we wrote about Boost Commerce being removed from the Shopify App Store after Shopify disabled its theme app extension, leaving some merchants with broken collection pages, missing search functionality, and storefronts that weren’t working as expected.

Eighteen days after the incident began, Boost reports its services are operational. However, important questions about the event remain unanswered.

Since our original article, we’ve spoken directly with Boost merchants who reported compromised storefronts. We’ve independently corroborated those accounts through agency contacts and individuals at Shopify speaking privately, not on behalf of the company. We’re protecting their identities at their request.

We’ve verified reports of compromised merchant storefronts, but we haven’t established that Boost’s infrastructure or code was responsible. That distinction is important, and we don’t want to suggest otherwise.

We’ve also received a cease-and-desist from Boost Commerce regarding our original article and have had dozens of merchants ask about our incident policies. What do we disclose? How quickly do we notify customers? Do we publish root-cause analyses?

We’ve had publicly documented policies covering these questions since well before the Boost incident. Given the amount of interest, we figured it was worth walking through them.

Where things are with Boost

Boost opened its public incident on October 17. The following day, it reported that the underlying issue had been fixed and Shopify had restored its theme app extension. By October 19, the incident was classified as resolved.

That gives merchants a timeline of when things stopped working and when they were restored, but not much else.

There’s still no detailed public explanation for why Shopify disabled the extension in the first place.

Separately, we’ve spoken with merchants who reported that their storefronts were compromised during the same period. We’ve corroborated those accounts through agency contacts and individuals at Shopify who spoke with us privately.

We’re not attributing those compromises to Boost without evidence establishing that connection. We haven’t independently determined the complete technical mechanism or the original point of entry.

But the reports themselves are credible, and they raise questions worth investigating.

Was unauthorized code served to shoppers? Which storefronts were affected? Was customer information exposed? What was done to verify that the affected stores were safe again?

As of November 4, we haven’t seen a substantive public explanation from Boost addressing those security concerns. That doesn’t establish that Boost was responsible for the reported compromises, but it does leave merchants without a clear public account of what happened.

Restoring service is obviously important, especially when merchants depend on that software to run their stores. But it’s not the same thing as explaining an incident.

We also received a cease-and-desist

On October 20, attorneys representing Boost Commerce sent us a cease-and-desist demanding that we remove or modify statements from our original article within seven days.

The letter focused primarily on our headline.

Specifically, Boost’s attorneys argued that describing the company as “dead” was defamatory because the word implies permanent unavailability. They also objected to our reference to collection pages disappearing, arguing that not every Boost merchant experienced that issue.

Our original article explicitly acknowledged that Boost had reported restoring its service. We weren’t claiming the company had permanently ceased operations, and the headline wasn’t intended to suggest every merchant lost their collection pages.

We found the literal interpretation of “dead” a little amusing, but the letter itself is a legitimate part of the story.

It didn’t dispute that Shopify had disabled Boost’s theme app extension or offer additional details about the underlying incident. Its objections concerned how we characterized the outage.

We compete with Boost Commerce, and readers must keep that in mind when evaluating our coverage. While we strive for accuracy, this article does not represent the views, positions, or official statements of Shopify or any company other than our own. If we have published something factually inaccurate, we welcome evidence and will correct it.

Our interest remains in understanding what happened and making sure merchants have the information they need.

A lot of merchants have been asking about our own policies

One thing we didn’t expect after publishing the first article was how many people would ask about our own incident response practices.

We’ve had dozens of questions over the past couple of weeks, mostly around what we’d disclose if something similar happened at Layers.

Would we notify merchants immediately? Would we publicly acknowledge a security incident? Would we share a root-cause analysis afterward? How much detail would we provide?

These are fair questions, particularly for software running directly on customer-facing storefronts.

Fortunately, they’re also questions we’ve already spent time answering.

Our incident response policy was last updated on September 3, more than six weeks before the Boost incident. It covers incident severity, escalation, communication timelines, recovery objectives, and post-incident reviews.

We don’t expect merchants to read through every vendor’s operational policies, but we do think that information should be available when they want it.

Here’s how ours works.

What happens when something breaks at Layers?

We classify incidents into four severity levels based on their impact.

A minor operational issue affecting a single merchant is different from a widespread storefront outage or a suspected security incident. We treat them differently, with communication and recovery requirements that vary by severity.

Security incidents are initially classified as SEV1, our highest severity, until we’ve established their scope.

For SEV1 incidents, our policy requires an initial status update within 30 minutes of declaration, with updates at least every 60 minutes until resolution. We also have a one-hour recovery time objective for storefront APIs and require a written post-incident review within five business days.

SEV2 incidents have slightly longer communication windows, with an initial update within one hour, updates at least every two hours, and a written review afterward.

For confirmed security incidents involving customer data, we notify the affected account’s security contact without undue delay and no later than 72 hours after confirmation.

That notification includes what happened, what data was involved, what we’ve done about it, and any actions we recommend the merchant take.

None of this was written in response to Boost. These are our existing procedures, and they’ve been publicly available for merchants to review.

You can read the full policy here.

How much do we actually make public?

Historically, everything.

We’ve made all our incidents visible to every Layers customer on our public status page, including minor outages and issues that affected only one or two merchants.

We’ve actually been so transparent about these smaller incidents that they’ve negatively affected the uptime percentages displayed by some public-facing automated status monitors.

Those monitors don’t always distinguish between a platform-wide outage and an isolated problem affecting a couple of tenants. An incident gets recorded, and the reported uptime percentage takes a hit, even if nearly every other merchant was operating normally.

It’s not particularly flattering when someone looks at the percentage without the context, but we’ve generally preferred to make more information available rather than less.

That said, we do reserve the right to limit visibility for genuinely isolated issues.

For example, if two or three merchants sharing an infrastructure cluster experience a localized problem, publishing it as a platform-wide incident can understandably worry merchants who aren’t affected.

In those cases, we may communicate directly with the affected merchants rather than broadcasting the issue to everyone.

That doesn’t change our notification requirements or what those merchants receive. They’ll still get the updates and post-incident information required by our policies.

We just don’t think an isolated issue affecting three stores should necessarily look like an outage affecting three hundred.

And what happens afterward?

For every SEV1 and SEV2 incident, we require a written post-incident review shared with affected customers.

It covers the timeline, root cause, customer impact, and what we’re changing to prevent the same issue from happening again. We also track corrective actions through completion rather than treating the review as the end of the process.

These reviews are blameless. We’re not particularly interested in figuring out who to point a finger at. We want to know why something failed, whether we caught it quickly enough, and what needs to change.

Sometimes that’s a code fix. Sometimes it’s better monitoring, an infrastructure change, or a process that requires adjusting.

We also recognize that there are limits to what can be responsibly disclosed, especially when an investigation involves sensitive customer information or security details that could pose additional risk.

But there’s a difference between withholding sensitive technical information and leaving affected merchants without a useful explanation.

If we’re still investigating something, we’d rather say that than pretend we already have all the answers.

We’ve had outages, too

We’re not writing this from the position that Layers has never had a problem.

We’ve experienced minor outages and isolated operational issues ourselves. That’s part of running infrastructure that merchants depend on, and it’s exactly why we have incident procedures.

Our systems power search, collections, merchandising, and other storefront experiences. When something breaks, even briefly, it can affect how shoppers interact with a store and potentially cost a merchant revenue.

We monitor our production infrastructure around the clock, with live checks across multiple regions, application and infrastructure monitoring, and critical alerts that page an on-call engineer.

We’ve also made architectural decisions to reduce the impact of certain failures, including keeping search and collection page implementations within the merchant’s own theme, with Shopify fallbacks available. We discussed some of that in our original article.

None of those things make us immune to incidents, and we wouldn’t claim otherwise.

Our incidents have involved minor operational disruptions, and we haven’t experienced any comparable confirmed security incidents.

What matters to us is that when something does go wrong, merchants aren’t left wondering whether we’re aware of it, what we’re doing about it, or whether they’ll ever hear the cause.

That’s why we documented our procedures long before any of this happened.

Eighteen days later

We compete with Boost Commerce. That’s not a secret, and we understand why some people might question our motives in covering their incident.

But we also believe merchants should be able to talk openly about what happened to their stores, and that credible reports of compromised storefronts deserve serious attention.

We’ve heard those reports directly and corroborated them through agency contacts and private conversations with individuals at Shopify. We continue to protect the identities of those sources at their request.

Boost has confirmed the disruption and subsequent restoration of service. What we still haven’t seen is a substantive public explanation addressing the security concerns those merchants have raised.

We hope that changes.

As for Layers, the questions we’ve received have prompted us to talk more openly about policies we’ve had in place for some time.

We’ve routinely made every incident visible to our customers, even when doing so made our uptime numbers look worse than the actual platform-wide impact. We have documented communication timelines, notification requirements, and written reviews for significant incidents.

We aren’t announcing those policies today. They’ve been there all along.

And while we hope merchants never need to rely on them, we think they should know what to expect if they do.

Our incident response policy is public, and we’d encourage merchants to ask the same questions of every vendor they depend on.