Shopify deletes a webhook subscription after 8 consecutive failed deliveries, and the warning email goes to the app’s developer, not to you. So the integration that pushes orders into your warehouse system can stop on a Tuesday and leave nothing red in your admin. You find out when a customer asks where their parcel is.
That is what a recurring check is for. Not to find bad tools, but to catch a working system that went quiet.
A martech health check is a fixed monthly pass over the systems that move your orders and report your money. You read the same six signals every month, compare each against a threshold you set in advance, and act only on the ones that trip. It is a calendar event, not a project, and it ends with a written decision.
This is for the operator who owns the store after launch
You run a Shopify or Shopify Plus store. Orders leave Shopify for a warehouse, an ERP or a 3PL. Numbers arrive from an ad account, an email tool and an analytics property, and they disagree by an amount nobody can explain. You are the person who gets asked which number is right.
This is not for the operator who has never taken an inventory of what runs on the storefront. That is a one-off job, and it has its own guide: what is still running on your store and how to find it. Do that once. The check below is what keeps the result true.
It is also not for a store that launched last quarter on one theme with five apps. Nothing has drifted yet. Start the monthly check at your first integration, not before.
The check tells you a signal moved. It does not tell you whether your tracking was ever correct in the first place. Confirming that events match real orders is analytics and attribution work. It is how Autonomous Technologies gets a Shopify operator down to one revenue number they can spend against. It needs store access, test transactions and a person. Treat it as a separate job with a separate owner.
Read the same six signals every month, and write down the number that trips each one
A check you improvise is a check you skip. Fix the list, fix the date, and fix the threshold before you look, so that reading the numbers is not the same act as deciding about them.
| Signal | Where you read it | The number that trips it | Your first move |
|---|---|---|---|
| Order handoff still firing | Shopify order count against the count in your ERP, 3PL or warehouse tool, same 28 days | Any gap above 0 orders | Check the app's webhook subscription before anyone re-keys an order by hand. |
| Revenue parity across systems | Shopify reports, ad accounts and email tool, one fixed 28-day window | A difference you cannot explain in one sentence | Reconcile one system at a time, starting with the one closest to the bank. |
| Analytics history long enough to compare | GA4 admin, data retention setting | Anything under 14 months | Set event-data retention to 14 months. Google deletes past the window monthly. |
| Email sender health | Google Postmaster Tools, user-reported spam rate | 0.10% to investigate, 0.30% to stop sending | Pause the send, clean the list, confirm one-click unsubscribe still works. |
| API version your integrations run on | Vendor release notes against Shopify's version schedule | Any version older than 12 months | Ask the vendor or your developer for the upgrade date in writing. |
| A named owner per system | Your own one-page inventory | Any row with an empty owner column | Fill the name in, or switch the system off. |
Two of those thresholds are judgement, and that is deliberate. Revenue parity and ownership depend on your business, so inventing a number for them would only give you false confidence. The other four are published, dated and not up for debate.
A silent integration failure costs more than a wrong number
A wrong number gets argued about. A stopped integration gets discovered by a customer.
Shopify’s own documentation sets out what happens when a webhook cannot be delivered. A webhook is a message Shopify sends to another system the moment something happens in your store, such as an order being paid. Per Shopify’s webhook delivery documentation, read 21 September 2026: if Shopify receives no response or an error, it retries 8 times over the next 4 hours. After 8 consecutive failures the subscription is automatically deleted, if it was configured using the Admin API. Warning emails go to the app’s emergency developer email address.
Read that last sentence again as a merchant. The alarm is wired to somebody else’s inbox.
Count the output, not the job status. A green scheduler and an installed app both tell you that code started. Only a count tells you it finished. Compare orders in Shopify against orders in the system downstream, over the same dates, every month. A gap of one order is a real signal, not a rounding error.
We hit the same principle from the build side on a white-label engagement for Part & Sum. A monthly reporting task that a person used to run by hand became an automated pipeline on a schedule. It carried two layers of idempotency, so that repeated processing had an explicit design. The published record is deliberately honest about the limit: production deployment and recurring execution have not been established in the available record.
That caveat is the lesson for your store. Shipping the automation and proving it ran this month are two different pieces of work, and only the second one is a health check.
A scheduled job nobody counts is a manual job with extra steps.
Your reporting window expires before the comparison you need most
Most operators discover their analytics retention setting in month 13. They go to compare this November with last November, and the rows are gone.
Google Analytics 4 lets a standard property keep event data for one of two periods: 2 months or 14 months. Google’s data retention documentation, read 21 September 2026, is blunt about what happens next. When data reaches the end of the retention period, it is deleted automatically on a monthly basis. Deleted means gone, not archived.
Fourteen months is the longer option, and it still does not give you a two-year view. So the monthly signal is not really “is retention correct”. It is “is anything I will want to compare next year living only in GA4”. If the answer is yes, export it somewhere you control.
Retention is a one-minute fix and a permanent loss. Changing the setting takes one click and applies going forward. It does not bring back a single deleted row. Check it on your first pass, not your fifth.
Email is the one signal with a published pass mark
Most stack arguments are about opinion. Deliverability is not, because Google published the numbers.
Google’s email sender guidelines, read 21 September 2026, tell senders to keep spam rates reported in Postmaster Tools below 0.3%, and recommend staying below 0.10%. The stricter rules apply if you send more than 5,000 messages per day to Gmail accounts. Google’s requirements for high-volume senders, read the same day, add two more: support one-click unsubscribe, and fulfil unsubscribe requests within 48 hours. That page also states that from November 2025, Gmail began ramping up enforcement on non-compliant traffic.
So the monthly reading is simple. Open Postmaster Tools, read the user-reported spam rate, and compare it with two published figures rather than with your own feeling about the last campaign.
Once a quarter, the check gets one more question
Integrations do not break at random. They break on dates the platform published in advance.
Shopify’s API versioning documentation, read 21 September 2026, sets the schedule. Shopify releases a new API version every three months, at 5pm UTC on the first day of the quarter. Each stable version is supported for a minimum of 12 months, with at least nine months of overlap. Version names are dates, such as 2026-04, so the age of any integration is readable at a glance.
| Cadence | What you check | Why this cadence and not another |
|---|---|---|
| Monthly, same date | The six signals above | Shopify removes a webhook subscription after 8 consecutive failures, so a month is already a long time to find out. |
| Quarterly, first week after 1 January, 1 April, 1 July, 1 October | Which integrations run on an API version heading out of support | Each stable version is supported for a minimum of 12 months, so a version over a year old is on borrowed time. |
| Annually | Consent wording, data retention, and who still holds admin access | These change with staff and regulation, not with platform releases. |
The quarterly question is one line long. Which of my integrations is running on a version that ages out within the next two quarters, and who is upgrading it?
What breaks during the check, and who owns each fix
The person who spots a signal is rarely the person who can act on it. Write the owner down before the signal trips, because the worst time to negotiate ownership is the week orders stopped flowing.
| Signal that trips | What breaks if nobody acts | Who owns the fix |
|---|---|---|
| Order handoff gap above 0 | Orders sit unshipped, and somebody starts re-keying them by hand | Whoever owns the app relationship, then your developer |
| Revenue parity gap | Budget decisions get made on the wrong number for a full month | Whoever runs paid media |
| Retention under 14 months | Next year's comparison has no data behind it | Your analytics owner |
| Spam rate over 0.30% | Campaigns land in spam for every customer, not just the complainers | Your email owner |
| API version over 12 months old | An integration stops on a date the vendor chose, not you | The vendor, with your developer verifying |
| An empty owner column | The check stops happening and nobody notices for two quarters | You |
One more rule keeps the document honest. No new tool goes onto the store without a row naming what it sends, where that lands, and who reads it. A stack stays checkable because adding to it costs a line of writing.
Martech health check questions Shopify operators ask
What is the difference between a martech health check and a stack audit?
A stack audit is a one-off teardown. You open the theme code and the admin, list every piece of third-party code still running, and delete what nobody owns. A health check is the recurring pass that comes afterwards: the same six signals, on the same date each month, each with a threshold decided in advance.
How long does the check take once it is set up?
The first pass is the long one, because you are writing the inventory and naming an owner for each system. After that you are reading six numbers and comparing them with last month’s, and the work moves to whatever tripped. Most months, nothing does.
Which signal should I add first if six is too many to start?
The order handoff count. Compare orders in Shopify with orders in the system that ships them, over the same 28 days. It is the only signal where a failure reaches a customer before it reaches a report.
Do I need extra tools to run this?
No. Five of the six signals are readable in tools you already have. That means the Shopify admin, your ERP or 3PL, your GA4 admin screen, Google Postmaster Tools and your vendors’ release notes. The sixth, the owner column, is a document you write once.
What should I do when the same signal trips two months running?
Stop treating it as a reading and treat it as a defect. One trip can be a slow week. Two consecutive trips means the fix never landed, so it needs a named owner, a date, and a note in the document explaining what changed.
