How built-in email automations behave when Stripe goes down
Most platforms like Thinkific or Teachable let you trigger email automations for things like failed payments or expiring subscriptions. Great. Until Stripe hiccups.
When Stripe throws a 409 or even a brief invalid API key error, your automation may halt — not just queue — halts. You won’t get an error log either. It just… doesn’t send the email.
That automation isn’t attempted again. It dies silently unless you build your own webhook retry system or fire a catch-all webhook to Zapier just in case.
I had a cohort model running in Podia with a 14-day payment grace period. Stripe glitched for about 90 minutes. I lost 12 retention emails that never fired and had zero way to refire without exporting a CSV and uploading back into Mailerlite.
There’s no visibility into partial-job queues in most of these tools. It’s either “Success” or “We won’t tell you.”
What should help: routing the automation through a buffer list (say, Tag = “Send retention attempts”) and having your ESP do the logic. More painful, far more observable.
A Thinkific support rep finally admitted: “Yes, if your payment processor returns a non-200 response, the automation won’t retry.” That one sentence spared me another 4 hours in log analysis.
Newsletter capture forms on landing pages: who owns the pixel?
Some platforms like Kajabi embed a Facebook or Google Remarketing pixel directly in the form embed script. No idea why they do this without warning you.
If you’re embedding that form on a standalone WordPress page — congrats! You’re now double-firing your own pixel and Kajabi’s.
One day I opened Facebook Ads Manager and saw double-conversions tagged in cold traffic. The pixelID wasn’t even mine. Traced it back using uBlock debug tools and found Kajabi’s unlisted marketing script.
The workaround: strip their auto-generated form embed and use plain HTML + their API endpoint for submission. You lose some design sugar but at least the pixel shenanigans stop.
Podia and Kartra don’t piggyback third-party pixels (last I checked), but always verify using DevTools, Network tab, filter by “pixel” or “event”.
If remarketing performance jumps or tanks with no design change, check if your LMS just rolled out a sneaky new onboarding integration. They push changes without explicit revisions.
SEO link cannibalization from dynamic course URLs
Teachable and Thinkific both use dynamic URLs with query params like ?preview=true or ?utm_source=dashboard in internal links. These get picked up by Google if improperly canonicalized.
So you end up with three indexed versions of your course sales page — one normal, one with preview state, and one with ref params — all competing on the same keyword anchor.
I had a Google Search Console crawl showing over 40 ‘duplicate without user-selected canonical’ entries. All from links they inserted into their own course preview pages.
You can’t edit those links unless you override the theme templates. Good luck finding where in Thinkific’s Liquid files they generate internal banners with tracker strings.
UGC-style comment widgets inside lessons usually generate their own canonical-breaking links too. Disable those if SEO matters.
The trick that finally helped: add a <meta name="robots" content="noindex,nofollow"> to the preview and non-authoritative versions using custom JavaScript injection and a page path match.
Oh, and never share your course link by copying the URL after hitting ‘Preview’. That’s not the real one — that’s just you making another indexed fragment.
When Zapier integrations stall during course enrollment spikes
Some course platforms throttle API hooks during sudden enrollment bursts. You won’t get a failure log. Zapier will just stop receiving data. Teachable confirmed this only after being pressed by our client’s CTO.
If your digital products trigger enrollment automations via Zapier (like: create email list contact, send fulfillment email, tag CRM), expect a random 3–5% of those to never happen during your highest sales hours.
Once ran a flash sale across three timezones and got 70+ DMs about people not receiving welcome emails. Found all their webhook push timestamps between 12:01 and 12:05 were missing.
This is not rate limiting at the Zapier end. This is silent discarding by the platform itself. Kartra and Kajabi seem especially aggressive about this.
Best option I’ve found: Don’t wait for Kajabi > Zapier > Mailchimp. Instead, write to your ESP directly using a webhook catch node. Or use Zapier’s Storage feature to log attempts and reprocess them in a loop if count below threshold.
One pattern we now use: course purchase > webhook > queue in worker > replay one-at-a-time to Zapier via named trigger. That thing has survived Black Friday spikes five times now.
Instagram bio links tracking is nonsense by default
Platforms will let you paste UTM-tagged links into your navigation. You stick it into a Button field labeled “Join Course.” Sounds solid.
When the browser prefetches, or the mobile app caches, your UTM campaign string becomes inconsistent — especially from inside Instagram. Welcome to ghost traffic hell.
Also, some mobile app wrappers (like Ladipage) will cut everything after the first & in a query string. So instead of utm_source=insta&utm_medium=linktree&utm_campaign=launch — you’ll end up with just the first one preserved.
I ended up writing a dumb redirector page that catches the full query string and parses it into a spreadsheet before redirecting to the actual Teachable link. Ugly, slow, but it gave me truth in traffic.
Nearly 58% of leads were showing up as “Direct” in GA4 (and still do), because course platforms redirect internally via window.location.replace() instead of server-side 301s. That kills referrer data.
Temporary workaround: embed a transparent iframe in the initial route with a hit URL to your own tracking domain. GA4 sees that as a true referral, not a blank.
Marketing emails sent from platforms often get throttled or junked
Teachable, Thinkific, and Podia all let you send marketing emails directly from the platform — but they don’t exactly warn you how that mail is being delivered.
Behind the scenes, it’s through an ESP-style pool address (often shared), and not your verified domain DKIM — unless you explicitly configure and wait 72 hours for DNS.
Which means: day one of your launch? You’re landing in Promotions or even Spam for half your Gmail subscribers.
One list we imported had warmed via Brevo (Sendinblue). Switched to Teachable’s broadcast tool. First email had a dismal 4-ish percent open rate — and 21 bounces, all Gmail-hosted.
Found out later: Teachable had recently switched backend mailing providers. DNS wasn’t updated. SPF was still referencing an old subprocessor. Dead mail before it ever started.
Fix: I now replicate every course announcement campaign in ConvertKit where I know deliverability is stable, and only use the platform’s emails for password delivery or critical alerts.
Heads up: Some of these platforms use Cloudflare Email Routing under the hood. If you’ve already set up that mail route, it gets flagged as duplicate SPF. Learned that one the ugly way.
“Course access revoked” triggers fire during billing sync bugs
Most platforms run a cron that checks subscription status every few hours. But syncing isn’t atomic with your payment gateway.
If your student updates a credit card while a renewal is cooking in the queue, and if the system gets the timing wrong, they may get marked as “canceled” for a few minutes.
Both Thinkific and Membervault have been seen firing “access_removed” automations right in that window. You get a trigger to Zapier or your webhook pipe, the customer receives an email: “access revoked.” Then five minutes later, all works again. That message sticks though.
This is demoralizing in a live cohort — when that one student posts a screenshot in your Slack saying “so… am I banned?”
A surprisingly effective bandaid we added: delay all access-removal Zaps by 5 minutes and refetch subscription metadata before continuing. If the status flipped back to active, suppress the email.
You would think they’d suppress automated messaging during billing transitions. They don’t. Neither Teachable or Thinkific have logic to suppress messages if a billing sync is happening in parallel.
Podia actually tracks this edge case slightly better by assigning a “retrying” state to subscription objects, but it never documents this in their webhook payload docs.
Sample payload we finally used to identify the difference:
If you see “retrying” — do not trigger any access change messages.
The preview link changing every time you update the course
Something weird I noticed: Thinkific aggressively regenerates preview tokens every time you make a material change, even as small as updating a section header or video thumbnail.
This makes it impossible to share a pre-launch preview link with teammates unless you’re all accessing the dashboard directly.
Even worse — if a student *has* access and you give them a preview link for later chapters they haven’t unlocked yet, it could 404 by the time they visit due to a stale auth token.
Bit the bullet and built a dummy pricing plan at $0 with a draft visibility flag and enrolled my test email just to simulate a student path. Not elegant, but stable URLs at least.
