Tracing Shopify Discount Changes Before and After a Sale

A sale that didn't end

The sale was meant to finish at midnight on Monday. On Wednesday morning, orders are still coming in with the code applied. Someone checks the discount in the admin, and the end date is now a week away.

The obvious questions follow. Who moved it? When? Was it meant to move, and nobody said so? Or did a quick edit to one setting change another by accident?

The discount itself can't answer any of those. It shows you what it says now. It does not show you what it said on Monday.

That gap is what makes discount problems awkward to investigate in a Shopify store. A wrong price on a product page gets noticed fast. A wrong discount setting usually gets noticed when the orders come in, after the margin is already gone.

Why discounts change more than you think

A discount looks like a simple object: a code and a percentage. In practice it carries several settings that each change what a customer pays.

The value. A percentage, a fixed amount, or free shipping.
The dates. When it starts and, optionally, when it ends.
The usage limits. A total number of uses, and whether each customer can use it only once.
The minimum requirements. A minimum purchase amount or quantity, or none.
The eligibility. Which products or collections it applies to, and which customers can use it.
The combinations. Whether it can be stacked with other discounts.

Each of these is a separate field, and each one can be edited on its own. Before a big sale, most of them get edited more than once. A team sets up a discount early, then changes the value after a planning meeting, then extends the dates to cover a preview, then loosens the minimum because early numbers look slow.

Every one of those edits might be right. The trouble is that two weeks later, nobody remembers which ones happened, in what order, or who made them.

The quiet failure modes

Discount mistakes tend to fall into a few patterns.

The end date moved, or was removed. A discount extended "just for the weekend" never had its end date put back. Or the end date was cleared while someone edited something else.

The usage limit was lifted. A single-use code meant for one customer had its limit removed. Now it works for anyone who has seen it, including anyone who found it on a coupon-sharing site.

The value changed after launch. A 15% discount became 25% for a flash window and stayed there.

The eligibility widened. A discount meant for one collection was switched to apply to all products. Items already at their lowest margin were now discounted too.

An app created or edited it. Email marketing, loyalty and referral apps often generate discount codes on your behalf. That is normal and useful. It also means that not every discount in your admin was made by a person on your team.

None of these produce an error. The storefront works and checkout works. The discount just does more, or for longer, than anyone meant it to.

What a useful record looks like

When you look into a discount problem, you need the same three things you need for any admin change.

Field-level before and after. Not "the discount was updated" but "the end date changed from the 18th to the 25th." Both values, kept. Adminlog tracks price rules among more than ten entity types, with field-level diffs. That turns "was the limit always unlimited?" into a question you can look up rather than argue about.

A timestamp. If discounted orders started outnumbering normal ones on a certain afternoon, a change from that afternoon is a strong lead. A timestamp also tells you whether the change came before or after the sale was announced, which often settles whether it was intended.

Honest actor attribution. Adminlog records whether a change came from a staff member, an installed app, or a system process, based on Shopify's own data. It does not guess. With discounts this matters because apps create and manage so many of them. If an app widened a discount, the fix lives in the app's settings, and the same thing will happen again until someone changes them. Blaming a colleague won't stop it.

What you can undo, and what you decide

It is worth being clear about scope here.

Adminlog's one-click revert is for products: it restores a product, or specific fields on it, to an earlier state. Discounts are not covered. For a price rule, the change record shows you exactly what changed and what the earlier value was. Putting it back is a decision you make yourself, in the Shopify admin.

That is usually the right way round for discounts anyway. A discount change is a commercial decision, not a typo in a description. Before reversing it you want to know why it was made. Maybe the end date was extended on purpose and nobody told support. Maybe the value was raised on purpose and nobody told finance. The record lets you ask the right person a specific question: "You changed this from 15% to 25% on Thursday at 4pm. Was that meant to stay?" That conversation takes a few minutes, not an afternoon of guessing.

A short discount check for the weeks before a sale

You don't need a heavy process. A few habits cover most of the risk.

Before the sale starts

List the discounts that should be active during the sale, with their intended value, dates and limits. Write it down somewhere the whole team can see.
Open each one in the admin and compare it with that list. Check the end date and usage limits first. Those are the settings most likely to have drifted.
Look for discounts you don't recognise. If an app created them, confirm that the app is meant to be running a promotion during the sale.

While it runs

If discounted orders look higher or lower than expected, check the change history for your sale discounts before changing anything. Find out what moved before you move it back.
Keep edits to a small number of people. That keeps the record readable as well as making mistakes less likely.

After it ends

Confirm that every sale discount actually stopped on time.
Review the changes made during the sale window. Note which were planned and which weren't. That list is the most useful input for planning the next sale.

The point is the record, not the blame

Most discount changes are made by people trying to help: extending a sale that is going well, or fixing a code a customer couldn't use. The problem is rarely the change itself. It is that nobody can see it afterwards.

A clear history of discount changes lets a team move quickly during a sale without losing track of what they did. When something does go wrong, it gives you a short, factual answer instead of a long search.

Adminlog records field-level changes to price rules, products, orders and more, with honest actor attribution and one-click product revert. If you want to know exactly what happened to your discounts this sale season, take a look at Adminlog.