One Two Three Send

Author: onetwothreeadmin

  • Monetisation dashboard refresh intervals: how often revenue updates

    You refresh your Stripe dashboard at 9am and see $247 in new revenue. You check again at 9:15am and the number hasn’t moved—but you know three customers just checked out because you got the order confirmation emails. So where’s the money?

    Revenue dashboards don’t update in real time, and each platform operates on a different delay. If you’re tracking daily revenue, reconciling payouts, or just trying to understand what’s actually happening with your business, knowing these intervals matters.

    Payment processor dashboard delays

    Stripe’s main dashboard updates every few minutes for successful charges, but refunds, disputes, and failed payment retries can lag by 15–30 minutes. The timeline view shows transactions almost immediately, but the balance graph—the one most operators check first—refreshes every 10 minutes and caches aggressively.

    PayPal’s dashboard has a reputation for slower updates. Standard transactions appear within 5–10 minutes, but subscription renewals and recurring payments sometimes take 30+ minutes to surface in the main balance view. The “Recent Activity” feed is faster, but it doesn’t always match the top-line numbers until the hourly rollup runs.

    Gumroad updates sales in near-real-time on the main dashboard, but the earnings graph—the one that shows net after fees—recalculates every hour. If you’re tracking margin, don’t trust the first number you see after a big launch.

    Membership and subscription platforms

    Platforms that sit on top of payment processors inherit their delays, then add their own.

    Memberful processes payments through Stripe, so completed charges appear almost immediately in Stripe—but Memberful’s own analytics dashboard updates every 15 minutes. The member count and MRR charts refresh overnight, so if you’re watching churn or upgrade velocity intraday, you’re looking at stale data.

    Patreon’s earnings dashboard updates twice daily: once around 8am Pacific and again around 8pm. If a patron pledges at 9am, you won’t see it reflected in your dashboard total until evening. The notification feed is real-time, but the dollar figure at the top isn’t.

    Substack shows new paid subscriptions within a few minutes, but the subscriber breakdown by tier—and the projected annual revenue number—updates every few hours. If you’re making pricing decisions based on tier distribution, pull the CSV export instead; the raw data is always current.

    Ad networks and affiliate dashboards

    Ad network dashboards are the slowest of all, because they’re waiting on third-party reporting.

    Beehiiv‘s ad network dashboard updates earnings once daily, around 6am Eastern. If you ran a sponsored placement yesterday, you won’t see attributed revenue until the next morning—and final numbers won’t settle for 48–72 hours as the network reconciles click-through conversions.

    Google AdSense updates estimated earnings every few hours, but the numbers aren’t final until the next day. The real-time reporting view shows impressions and clicks with a 10-minute lag, but the revenue estimate attached to them recalculates on a slower cycle. If you’re troubleshooting a sudden RPM drop, wait until tomorrow before panicking.

    Affiliate dashboards vary wildly by network. Amazon Associates updates every 2–3 hours, but conversions can take 24 hours to appear if the customer clicked late at night. Impact and ShareASale update conversions within the hour, but commission amounts don’t finalize until the advertiser approves the sale—sometimes days later.

    What to do about it

    First, stop refreshing. Pick one time each day to check revenue—preferably after your slowest platform has updated. If Patreon only refreshes twice daily, checking Stripe every ten minutes just creates anxiety and bad decisions.

    Second, reconcile weekly, not daily. Payment processor dashboards show gross revenue; your bank account shows net after fees, refunds, and holds. The two will never match on the same day, and trying to force them into alignment wastes time.

    Third, use webhook notifications for anything time-sensitive. If you need to know the instant a high-value customer subscribes, set up a Slack or email alert via your payment processor’s webhook system. Don’t rely on dashboard-refresh habits for operational awareness.

    Finally, export raw data when you need precision. Every monetisation platform offers CSV downloads with transaction timestamps and final amounts. If you’re building a financial model or reconciling taxes, the dashboard is a preview—the export is the source of truth.

    Want more breakdowns of how online-business tools actually work? Subscribe to One Two Three Send for weekly deep-dives into the features, delays, and design decisions that shape how you operate.

    Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

  • WordPress CDN purge delays: why cache clears take five minutes

    WordPress CDN purge delays: why cache clears take five minutes

    WordPress CDN purge delays: why cache clears take five minutes
    Photo: Matinbeigi via Wikimedia Commons (CC BY-SA 4.0)

    You hit “Publish” on a post correction, purge the CDN cache, refresh the page—and the typo’s still there. You wait. Refresh again. Still wrong. Five minutes later, it updates.

    CDN cache purging isn’t instant. Most providers propagate purge commands through distributed edge networks, and that takes time. If you’re running a content business on WordPress, understanding actual purge timing prevents panic refreshes and helps you decide when a full-site purge is worth the performance cost.

    How CDN purge propagation actually works

    When you purge a cached object—a page, an image, a CSS file—the CDN doesn’t instantly delete it from every edge server worldwide. Instead, your purge request hits the CDN’s API, gets queued, then propagates to regional points of presence (PoPs). Each PoP marks the object stale or removes it, depending on the provider’s architecture.

    Cloudflare’s purge-by-URL typically completes in 30 seconds globally, though they quote “up to 30 seconds” as a best-case median. Fastly averages under five seconds for most objects but can stretch to 15–20 seconds during high load. BunnyCDN usually clears within 10–30 seconds. StackPath and KeyCDN sit around 60–90 seconds for full propagation.

    Those are averages. Edge cases—literal and figurative—happen. A PoP in Sydney might lag behind one in Frankfurt. If your reader’s browser cached the HTML before the purge, they’ll still see stale content until their local cache expires or they hard-refresh.

    What happens during the lag

    Between purge initiation and full propagation, some visitors see the old version, others see the new one. If you’re fixing a pricing error or a broken affiliate link, that inconsistency matters.

    WordPress caching plugins like WP Rocket, W3 Total Cache, and LiteSpeed Cache trigger CDN purges via API when you update a post. But they don’t wait for confirmation. The plugin fires the request, WordPress shows you the updated post in the admin, and you assume it’s live everywhere. It’s not—yet.

    If you need guaranteed consistency, purge the specific URL, wait two minutes, then check from an incognito window or a mobile device on cellular (different network path, different edge server). Don’t rely on your own cached browser session.

    Selective purge vs. full-site purge

    Most WordPress caching plugins offer two purge modes: purge this page, or purge everything. Purging a single URL is fast and surgical. Purging the entire cache forces every page, image, and asset to reload from your origin server until the CDN re-caches them.

    A full-site purge sounds safe—no stale content anywhere—but it costs you. For the next 10–30 minutes, your origin server handles traffic it normally wouldn’t. If you’re on shared hosting or a low-tier VPS, that spike can slow response times or trigger rate limits. BigScoots and other managed hosts handle it better, but you still lose the speed benefit of edge caching until the CDN rewarms.

    Purge selectively unless you’ve changed something global: a CSS file, a header template, or site-wide navigation. If you fixed one post’s typo, purge that post’s URL and its homepage listing. That’s it.

    When browser cache makes CDN purge irrelevant

    CDN purge only matters if the CDN is the bottleneck. If you set aggressive browser cache headers—say, one year for HTML—visitors won’t even request the page from the CDN. Their browser serves the cached copy until the cache-control max-age expires.

    Check your caching plugin’s browser cache settings. WP Rocket defaults to one year for static assets (images, CSS, JS) but typically one hour or less for HTML. LiteSpeed Cache lets you set per-file-type TTLs. If your HTML cache TTL is longer than your CDN purge time, the CDN purge won’t help users who visited before the update.

    The fix: keep HTML browser cache short (3600 seconds or less) or version your URLs when you make critical changes. Most plugins handle CSS/JS versioning automatically via query strings, but HTML doesn’t get that treatment.

    Tool-specific purge behavior

    Cloudflare’s WordPress plugin purges the updated post, the homepage, any archive pages that list it, and related tag/category pages. Selective, but broader than just the post URL. Fastly’s plugin (less common) purges by surrogate key, which batches related objects—faster propagation but requires tagging setup.

    WP Rocket integrates with Cloudflare, StackPath, and Sucuri CDNs via API. When you save a post, it purges the post URL and any pages you’ve configured in settings. W3 Total Cache supports a longer CDN list but requires manual API key entry and sometimes fails silently if credentials expire.

    If purges aren’t working, check your plugin’s CDN settings. API tokens expire, rate limits get hit, and some hosts block outbound API calls from PHP. You’ll see no error in WordPress—just stale content that won’t budge.

    Want more infrastructure breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives into the tools that run your online business—no fluff, just what actually happens under the hood.

  • Canva’s Brand Kit tier limits: when color palettes hit the wall

    Canva’s Brand Kit tier limits: when color palettes hit the wall

    Canva's Brand Kit tier limits: when color palettes hit the wall
    Photo: Vijay Verma via Wikimedia Commons (CC0)

    Canva’s Brand Kit feature centralizes your visual identity—logos, fonts, color palettes—so every graphic you create stays on-brand. It’s one of the platform’s most useful features for solo operators who don’t want to manually copy hex codes or hunt for the right logo file every time they make a social post.

    But the Brand Kit isn’t one-size-fits-all. Canva gates the feature across three tiers—Free, Pro, and Teams—and each tier imposes hard limits on how many palettes, fonts, and logos you can store. Hit those limits mid-project, and you’re stuck either deleting old assets or upgrading.

    Here’s what each tier actually allows, when you’ll hit the ceiling, and how to work around it without paying more than you need to.

    What each tier lets you store

    Canva Free: One brand kit total. Inside that kit, you get one color palette (up to three colors), one font pairing, and one logo upload. That’s it. If you run multiple projects—say, a newsletter and a podcast with different visual identities—you can’t store both. You’ll need to manually swap assets every time you switch contexts.

    Canva Pro: Unlimited brand kits. Each kit supports up to 100 color palettes, 100 font pairings, and 100 logos. For most solo operators, this is more than enough. The real constraint here isn’t the cap—it’s organization. Once you’ve got 30+ palettes saved, finding the right one becomes a search problem.

    Canva for Teams: Same storage limits as Pro (100 per asset type per kit), but designed for shared access. Multiple users can edit and apply the same Brand Kit. Pricing starts at $100/year for up to five people, so it’s overkill unless you’re actually collaborating with a team or VA.

    When you’ll hit the limit

    If you’re on Free, you’ll hit the wall immediately if you manage more than one brand. The single-kit limit forces you to choose: either keep everything under one visual identity, or manually re-upload assets every time you switch projects.

    On Pro, the 100-palette cap sounds generous, but it sneaks up on you if you create seasonal campaigns, A/B test color schemes, or work with clients. Each palette can only hold three colors, so if you’re building out a full brand system with primary, secondary, and accent palettes, you’re using multiple slots per brand. Operators who run paid template libraries or design-heavy newsletters can burn through 30–40 palettes in a year.

    The font pairing limit (also 100) is rarely a problem. Most operators settle on two to three pairings and stick with them. Logos, same deal—unless you’re managing client work or sub-brands, you won’t approach the cap.

    Workarounds that don’t require an upgrade

    Archive unused palettes quarterly. Canva doesn’t let you export a Brand Kit as a backup file, but you can screenshot your palettes or copy hex codes into a note. Delete seasonal or one-off palettes after campaigns end, and restore them manually if you need them again later. It’s tedious, but free.

    Consolidate palettes using external color management. Instead of saving every variation in Canva, store your full color system in a tool like Coolors or a simple spreadsheet. Keep only your two to three most-used palettes in Canva’s Brand Kit, and copy-paste hex codes for edge cases. This keeps your Brand Kit lean and searchable.

    Use templates as palette storage. Create a blank Canva design, fill it with color swatches, and save it as a reusable template. You can duplicate the template anytime and eyedropper the colors into new designs. It’s a hack, but it bypasses the Brand Kit limit entirely.

    When upgrading actually makes sense

    If you’re solo and on Free, the $120/year Pro upgrade is worth it the moment you manage two distinct brands. The jump from one kit to unlimited eliminates the constant asset-swapping friction.

    If you’re already on Pro and hitting the 100-palette limit, pause before upgrading to Teams. The extra cost ($100/year vs. $120/year for Pro) doesn’t increase storage—it only adds collaboration features. Instead, audit your saved palettes. Most operators find that 60–70% of their stored palettes are outdated or redundant. Delete those, and you’ll buy yourself another year before the cap matters again.

    Teams makes sense only if you’re actually sharing brand access with collaborators—a VA formatting posts, a designer building templates, or a co-founder who needs the same visual assets. If it’s just you, Pro is the ceiling.

    One non-obvious tip: Canva’s Brand Kit color picker auto-suggests palettes based on uploaded logos. If you upload a logo with your full color system embedded, Canva will extract a palette for you. Use this to quickly populate a new Brand Kit without manually entering hex codes—but double-check the extracted colors against your source file, because Canva’s algorithm sometimes picks slightly off-brand shades.

    Managing multiple brands or seasonal campaigns? Reply and tell us how you organize your color systems—we’ll feature operator setups in a future issue.

  • AI content detectors flag human writing 30% of the time—why

    AI content detectors flag human writing 30% of the time—why

    AI content detectors flag human writing 30% of the time—why
    Photo by nedimshoots on Unsplash

    AI content detectors have become gatekeepers for sponsorships, guest posts, and platform monetization. The problem: they’re wrong about a third of the time, flagging human-written work as machine-generated.

    If you run a content business, you’ve probably hit this wall. A sponsor asks you to run your draft through an AI detector before approval. A platform threatens demonetization. Or a client demands proof that you didn’t use ChatGPT.

    Understanding why these tools fail—and how to navigate the accusation—matters more than ever in 2026.

    What triggers false positives

    AI detectors work by analyzing patterns: sentence structure, word choice, predictability. They compare your text against statistical models of how large language models “sound.”

    The trouble is that clear, concise writing often matches those patterns. If you write with short sentences, simple vocabulary, and logical flow—exactly what good online writing demands—you’re more likely to get flagged.

    Specific triggers include:

    • Repetitive sentence structure: Three sentences in a row that start with a subject-verb pattern look algorithmic.
    • Low perplexity: Predictable word choices. If a human reader can guess the next word easily, a detector assumes a model wrote it.
    • Domain-specific jargon used generically: Writing about “optimizing conversion funnels” or “improving email deliverability” hits phrases AI models were trained on heavily.
    • Neutral tone: Lack of contractions, idioms, or personal asides makes text feel generated.

    One operator I spoke with had a 1,200-word how-to guide on WordPress caching flagged at 78% AI-generated. She’d written it from scratch in Google Docs with revision history to prove it. The detector didn’t care.

    Why detectors can’t be trusted for enforcement

    The major AI detection tools—Originality.AI, GPTZero, Copyleaks—report accuracy rates between 85% and 95%. That sounds high until you realize a 10% false positive rate means one in ten human authors gets accused incorrectly.

    At scale, that’s catastrophic. If a newsletter platform uses detection to auto-flag content, thousands of legitimate operators get caught in moderation queues.

    Worse, detectors can’t distinguish between:

    • Human writing that happens to be clear and direct
    • Human writing that was edited by AI (reworded sentences, tightened paragraphs)
    • Fully AI-generated text that a human lightly revised

    The tools aren’t measuring authorship—they’re measuring stylistic similarity to training data. That’s a proxy, not proof.

    How to handle the accusation

    When a sponsor, platform, or client demands you prove your work is human-written, you have three options.

    Option one: Provide process evidence. Share your Google Doc or Notion page with full revision history. Show drafts, timestamps, and editing activity. It’s not foolproof—someone could still claim you pasted AI output and edited—but it establishes a paper trail most AI-generated work lacks.

    Option two: Rewrite the flagged sections. If a detector highlights specific paragraphs, rework them with more varied sentence openings, contractions, or personal voice. It’s frustrating to edit work that’s already good, but sometimes it’s faster than arguing.

    Option three: Refuse and explain why. If you’re confident in your process and the relationship allows it, push back. Explain that detectors produce false positives at high rates and that stylistic clarity shouldn’t be penalized. This works better with long-term clients than one-off sponsors, but it’s worth trying.

    One content operator now includes a rider in sponsorship contracts: “Sponsor may request up to two revisions for clarity or brand alignment, but may not reject work solely based on third-party AI detection tool output.” It’s worked twice to shut down bad-faith objections.

    What this means for your workflow

    If you use AI tools to brainstorm, outline, or edit—many solo operators do—you’re in a gray zone. A draft that starts human, gets expanded by Claude, then edited back by you will almost certainly trigger detectors.

    That doesn’t make it unethical, but it does make it risky if clients or platforms treat detection scores as binary verdicts.

    The practical move: decide where you draw the line, document your process, and be ready to show your work. Save outlines, keep drafts in version-controlled tools, and screenshot your workflow if a dispute arises.

    AI detectors aren’t going away. Platforms and sponsors will keep using them because they’re cheap and feel objective. But they’re not accurate enough to be the final word on authorship—and you shouldn’t let them be.

    Want more on AI tools, workflows, and the mechanics of running a content business? Subscribe to One Two Three Send for operator-to-operator breakdowns every day.

    Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

  • SEO keyword cannibalization: how to audit and fix competing pages

    SEO keyword cannibalization: how to audit and fix competing pages

    SEO keyword cannibalization: how to audit and fix competing pages
    Photo by Lukas Müller on Unsplash

    Keyword cannibalization sounds exotic, but it’s just a fancy term for a common problem: you’ve published multiple pages that compete for the same search intent, and Google can’t figure out which one you want to rank.

    The result? Neither ranks well. Or worse, Google picks the weaker page and ignores the one you actually want in the top ten.

    This happens more often than you’d think—especially if you’ve been publishing steadily for a year or more. A how-to guide from 2024, a roundup from 2025, and a comparison post from this year might all target variations of the same keyword. Google sees overlap, splits authority, and your rankings stall.

    Here’s how to audit for it, decide what to keep, and fix it without tanking your traffic.

    Step one: find competing pages

    Open Google Search Console. Go to Performance, filter by query, and look for keywords where you have multiple pages showing impressions.

    Click into a high-priority keyword—something you actually want to rank for. Under the Pages tab, you’ll see which URLs are appearing in search results for that query. If you see two or more pages splitting impressions, you’ve got potential cannibalization.

    Not every overlap is a problem. If one page gets 90% of impressions and another gets 10%, that’s noise. But if two pages are splitting impressions 50/50 or 60/40, Google’s confused.

    Export the list. You’ll want a spreadsheet with keyword, URL 1, URL 2, impressions for each, and average position for each.

    Step two: decide which page should win

    Look at each pair of competing pages and ask:

    • Which one better matches search intent for this keyword?
    • Which one has more backlinks or existing authority?
    • Which one is more current, complete, or useful?

    Sometimes the answer is obvious—your definitive guide should outrank a quick-hit blog post. Other times it’s murkier. A 2024 post might have more backlinks, but a 2026 update might be more accurate.

    In that case, you’re not choosing between pages—you’re merging them. More on that in a second.

    Mark your winner in the spreadsheet. That’s the page you’re going to strengthen. The loser gets deleted, redirected, or rewritten to target a different keyword.

    Step three: consolidate or differentiate

    You have two options: merge the content or split the intent.

    Option A: Consolidate. Take the best parts of both pages and fold them into the winner. Update the publish date if it makes sense. Then 301-redirect the weaker URL to the stronger one. This passes link equity and tells Google the old page is gone for good.

    This works best when both pages are trying to answer the same question and there’s no good reason to keep them separate.

    Option B: Differentiate. Rewrite one page to target a different keyword or angle. If you’ve got a “best email tools” post and a “best email tools for solo founders” post, lean into the difference. Make one broader, the other hyper-specific. Update the title tag, H1, and intro to clarify the distinction.

    Add internal links between them if it makes sense, but make sure the on-page signals are distinct enough that Google knows which page to show for which query.

    What to expect after the fix

    Rankings won’t shift overnight. Google needs to recrawl both pages, reprocess the redirect (if you added one), and re-evaluate which page should rank.

    In most cases, you’ll see movement within two to four weeks. The winning page usually climbs a few spots as authority consolidates. If you redirected a page with backlinks, expect a small ranking bump once Google processes the signal.

    If you differentiated instead of merged, watch Search Console for the next month. You should see impressions for each keyword start to separate—one page dominates keyword A, the other dominates keyword B.

    The mistake most operators make is doing this once and never revisiting it. Cannibalization creeps back in as you publish. Set a calendar reminder to audit your top 20 keywords every quarter. It takes 30 minutes and catches problems before they cost you traffic.

    Got a question about SEO, traffic strategy, or tooling? Reply to this email—operator questions shape what we cover next.

  • Payment processor webhook retry logic: how long they wait before giving up

    Payment processor webhook retry logic: how long they wait before giving up

    Payment processor webhook retry logic: how long they wait before giving up

    When your server misses a payment webhook—because your hosting provider had a blip, your endpoint timed out, or you deployed code at the wrong moment—you’re relying on the processor’s retry logic to deliver it again. But each platform handles retries differently, and the windows are shorter than most operators assume.

    Miss the retry window entirely, and you’ll never know that subscription was canceled, that payment failed, or that refund was issued. Here’s what actually happens behind the scenes.

    Stripe: exponential backoff over three days

    Stripe retries failed webhooks with exponential backoff. The first retry happens within minutes. Subsequent attempts spread out over roughly three days, with the final attempt landing around 72 hours after the initial event.

    If your endpoint returns anything other than a 2xx status code—or times out after 30 seconds—Stripe marks it as failed and queues a retry. The dashboard shows each attempt, including response codes and timing.

    The three-day window sounds generous, but if your server is down for a long weekend or you’re troubleshooting a bug that takes four days to identify, you’ve lost the event. Stripe doesn’t retry indefinitely.

    Non-obvious detail: Stripe disables your webhook endpoint automatically after multiple consecutive failures across different event types. You’ll get an email, but if you’re not monitoring closely, subscription updates can go silent for days before you notice.

    Paddle: 72-hour retry, then manual replay required

    Paddle’s retry behavior mirrors Stripe’s three-day window but with a stricter cutoff. After 72 hours, failed webhooks stop retrying. To recover them, you need to manually request a replay through the dashboard or API.

    The replay feature is helpful if you know what you’re looking for—filter by event type and date range, then trigger a resend. But it requires you to notice the gap first. If a handful of subscription.updated events went missing during a deploy and you don’t audit logs regularly, you might not realize users were downgraded or upgraded until they complain.

    Paddle also enforces the same 30-second timeout as Stripe. If your webhook handler queries a slow database or chains multiple API calls, you’ll hit that ceiling faster than expected.

    Lemon Squeezy: five retries over 24 hours, then it’s gone

    Lemon Squeezy retries webhooks five times over approximately 24 hours. The schedule isn’t publicly documented down to the minute, but the final attempt lands within a day of the original event.

    This tighter window means less room for error. If you deploy a breaking change Friday afternoon and don’t catch it until Monday, you’ve missed every webhook that fired over the weekend. Unlike Stripe and Paddle, Lemon Squeezy doesn’t surface retry history in the dashboard with the same granularity—you’ll see that an event was sent, but forensic details are limited.

    The shorter retry window makes Lemon Squeezy less forgiving for solo operators who don’t monitor uptime 24/7. It’s workable if your stack is stable, but the margin is thin.

    What to do when retries aren’t enough

    Webhook retries are a safety net, not a guarantee. If you’re running a subscription business, you need a second layer: periodic reconciliation.

    Once a day—or once a week, depending on volume—query your payment processor’s API for subscription and payment statuses, then compare them against your database. Look for mismatches: active subscriptions in Stripe that your app thinks are canceled, payments marked pending that actually settled, refunds that never updated your records.

    This reconciliation step catches what retries miss. It’s not real-time, but it prevents the worst-case scenario where a customer’s access is wrong for weeks because a single webhook disappeared.

    Set up logging that writes every incoming webhook to a separate table before processing it. If your handler crashes mid-execution, you’ll still have the raw payload to replay manually. Most processors let you trigger test webhooks from the dashboard—use those to validate your endpoint handles retries and errors correctly before real money flows through.

    Want more architecture breakdowns like this? Subscribe to One Two Three Send—every article is written for operators running the business, not just the content.

    Set up alerts, not just logs

    Failed webhooks usually show up in your payment processor’s dashboard, but dashboards require you to look. Set up an alert—Slack notification, email, SMS, whatever you’ll actually see—when your endpoint returns a non-2xx status or when the processor reports multiple failures in a row.

    If you’re on a platform like Stripe, enable the option to email you when an endpoint is disabled. That email might be the only signal you get before revenue events start disappearing.

    Webhook retries buy you time to fix an outage, but they don’t extend indefinitely. Understand your processor’s retry schedule, build reconciliation into your workflow, and monitor failures in real time. The three-day window Stripe offers feels comfortable until you realize you didn’t check the dashboard for four.

  • ConvertKit’s visual automation builder: when branches multiply, performance tanks

    ConvertKit’s visual automation builder: when branches multiply, performance tanks

    ConvertKit's visual automation builder: when branches multiply, performance tanks
    Photo: Hannah Krafcik via Wikimedia Commons (CC BY-SA 4.0)

    ConvertKit’s visual automation builder is one of the cleanest interfaces in email marketing. Drag a trigger, add conditions, branch subscribers into different paths—it feels intuitive until you hit about 40 nodes and the canvas starts choking.

    If you’re running a content-driven business with segmented onboarding, product launches, or behaviour-based nurture sequences, you’ve probably felt this. The builder loads slowly. Clicks lag. Moving a single node can freeze your browser for three seconds.

    This isn’t a bug—it’s a design tradeoff. Visual builders prioritise clarity over scalability, and ConvertKit’s canvas renders every node, connection, and conditional rule in real time. Past a certain threshold, that becomes expensive.

    When the visual builder works perfectly

    ConvertKit’s automation canvas excels at linear workflows with light branching. If you’re building a welcome sequence that forks based on one or two subscriber actions—clicked a link, purchased a product, tagged as interested in Topic A vs. Topic B—the visual layout makes logic auditable at a glance.

    A typical high-performing automation in this range:

    • One trigger (subscribed to a form)
    • 3–5 emails spaced over 7–14 days
    • 2–3 conditional branches based on clicks or tags
    • 1–2 goal events that exit subscribers early

    Total node count: 15–25. The canvas loads instantly. Changes save in under a second. You can onboard a VA or collaborator by screenshotting the flow.

    Where it breaks down

    Problems appear when you start layering complexity:

    Nested conditionals. Branch on purchase status, then branch again on engagement level, then fork by content preference. Each layer doubles your node count. A four-level decision tree can balloon to 60+ nodes before you’ve sent ten emails.

    Event-based re-entry. If your automation triggers on “tag added” and you’re using tags liberally across your system—post interactions, product interest signals, engagement scores—subscribers can enter the same automation multiple times. ConvertKit handles this, but visualising those re-entry paths on a single canvas creates spaghetti.

    Time delays at scale. ConvertKit’s visual builder treats every wait period as a discrete node. If you’re spacing emails across 90 days with variable delays based on activity, you’re adding 10–15 wait nodes just for pacing. Combine that with branching and you’re over 50 nodes easily.

    At that scale, the canvas becomes a liability. Loading takes 8–12 seconds. Dragging nodes to reorganise triggers a visual refresh that can pause your browser. Editing a condition three layers deep requires zooming, panning, and waiting for the interface to catch up.

    The workaround: split automations and use sequences

    ConvertKit offers two tools for sending automated emails: visual automations and sequences (the older, list-based drip feature). Most operators default to automations because the interface is newer and more flexible. But sequences are faster, simpler to manage, and handle high-volume evergreen content better.

    Use sequences for linear email courses or onboarding. If your workflow is mostly “send email 1, wait 2 days, send email 2, wait 3 days…” with minimal branching, a sequence is faster to build and never lags. You lose conditional logic, but you gain speed and reliability.

    Use automations for decision points, then hand off to sequences. Build a short automation (under 20 nodes) that handles the initial triage—tag based on link clicks, segment by purchase history, apply a custom field. Then use an action step to subscribe users to the appropriate sequence. The sequence handles delivery; the automation handles routing.

    This hybrid approach keeps individual automations lightweight and makes debugging easier. If a subscriber isn’t receiving emails, you can check the sequence separately from the routing logic.

    Split large automations by goal or time horizon. Instead of one 60-node “master onboarding” automation, build three:

    • Days 1–7: Welcome, core content, initial segmentation
    • Days 8–30: Nurture based on engagement tags
    • Days 31+: Long-term re-engagement or upsell

    Each automation stays under 25 nodes. Subscribers flow from one to the next via tags or custom field updates. You lose the single-canvas overview, but you gain maintainability.

    One non-obvious tip: name every node

    ConvertKit lets you label individual automation nodes with custom names. Most people skip this. Don’t.

    When you’re troubleshooting why a subscriber didn’t receive an email, ConvertKit’s activity log shows which automation nodes they passed through—but only by name. If all your conditional branches are labelled “Condition” and all your emails are “Email,” the log is useless.

    Name every node descriptively: “Check if purchased Product A,” “Send case study email—Topic B,” “Wait 3 days after click.” It takes an extra 10 seconds per node when you’re building, but it saves 10 minutes every time you debug.

    If you’re running ConvertKit automations that feel sluggish or impossible to audit, the problem isn’t the tool—it’s the architecture. Keep individual automations under 30 nodes, offload linear sequences to the sequence builder, and split complex workflows by stage. The visual builder works best when you don’t ask it to do everything at once.

    What’s the most complex automation you’ve built? Hit reply and let me know where it broke—I’ll feature anonymised examples in a future roundup.

  • WordPress staging environment sync: when to push down vs. pull up

    WordPress staging environment sync: when to push down vs. pull up

    WordPress staging environment sync: when to push down vs. pull up

    Most WordPress hosts now include staging environments—a cloned copy of your live site where you can test plugin updates, theme changes, or new integrations without risking downtime. The setup is simple: click a button, wait a few minutes, and you’ve got a sandbox.

    But the real decision isn’t whether to use staging. It’s which direction to sync, and when.

    Most operators treat staging as a one-way mirror: clone production down, test changes, push them back up. That works for plugin updates and design tweaks. But it breaks down when your live site has dynamic data—new posts, form submissions, user signups, or orders—that didn’t exist when you cloned.

    Here’s how to decide which sync direction fits your workflow, and what breaks when you pick wrong.

    Pushing down: when fresh data matters more than continuity

    Pushing down means cloning your live site onto staging. You overwrite whatever’s currently in staging with a fresh snapshot of production. This is the default behavior for most hosts—and it’s the right move when you’re testing something that depends on current content or user data.

    Use push-down sync when:

    • You’re testing a new analytics plugin and need real post data to verify tracking
    • Your live site has grown significantly since the last clone (new posts, pages, or taxonomy terms)
    • You’re debugging a performance issue that only appears with production-scale database size
    • You need to test a membership plugin against actual user roles and subscription states

    The tradeoff: anything you built or configured in staging gets erased. If you spent two days setting up a new WooCommerce flow in staging, then pushed production down to test a different plugin, that work is gone.

    Most hosts don’t warn you. BigScoots’s staging tool does show a confirmation dialog, but it’s easy to click through without reading.

    Pulling up: when you’ve built something new in staging

    Pulling up means pushing your staging environment to production. You overwrite the live site with whatever you built in the sandbox. This is how you deploy new features, redesigns, or structural changes you’ve tested in isolation.

    Use pull-up sync when:

    • You’ve built a new landing page or section in staging and want it live
    • You’ve reconfigured permalink structures, custom post types, or taxonomies
    • You’ve tested a major plugin update (e.g., WooCommerce, Elementor) and want to deploy it
    • You’ve migrated content from another CMS into staging and validated the import

    The danger: you’ll overwrite any content published on the live site since the last clone. If your staging environment is three days old and you pull it up, any posts, comments, form entries, or orders created in those three days vanish.

    This is catastrophic for active sites. If you publish daily or run e-commerce, you can’t safely pull staging up without losing data unless you’ve frozen live updates.

    Selective sync: the middle path most hosts don’t offer

    The ideal workflow is selective sync—pushing only files (themes, plugins, uploads) or only database tables (posts, settings, users) in either direction. Most one-click staging tools don’t support this. They’re all-or-nothing.

    If you need selective sync, you have two options:

    Manual export/import: Use a plugin like WP Migrate DB to export specific tables from staging, then import them into production. You can exclude tables (e.g., skip wp_posts to avoid overwriting live content, but import wp_options to deploy new settings). This takes longer but gives you control.

    File-level deployment: If you’re only changing theme files or custom plugins, skip the staging push entirely. Use SFTP or Git to deploy files directly to production, leaving the database untouched. This is faster and safer for code-only changes, but requires you to track which files changed.

    The sync direction checklist

    Before you click the sync button, ask:

    • Has live content changed since I cloned staging? (Check post count, user count, or recent order IDs.)
    • Did I build anything in staging I need to keep? (New pages, plugin configs, theme customizations.)
    • Am I testing something that needs fresh data, or deploying something I built?
    • Can I afford to lose three days of live content, or three days of staging work?

    If the answer to both “Has live content changed?” and “Did I build anything in staging?” is yes, you’re in a conflict state. Don’t sync in either direction. Export what you built in staging manually, push production down to refresh staging, then re-import your changes and test again before pulling up.

    Most staging failures aren’t technical. They’re directional. The button works fine—it just does exactly what you told it to, in the wrong direction, at the wrong time.

    What’s your staging workflow? Reply with how you handle sync direction—I’m collecting operator setups for a follow-up piece on staging best practices.

  • LinkedIn carousels export at 1080×1080—here’s the workaround

    LinkedIn carousels export at 1080×1080—here’s the workaround

    LinkedIn carousels export at 1080×1080—here's the workaround
    Photo by Mariia Shalabaieva on Unsplash

    LinkedIn’s carousel post format—technically called document posts—lets you upload PDFs that readers swipe through like Instagram carousels. It’s a solid format for reaching professional audiences without leaving the platform.

    But there’s a design constraint nobody mentions until after you’ve built your first deck: LinkedIn exports every carousel slide as a 1080×1080 pixel square, regardless of what you uploaded. If you designed slides in 16:9 widescreen or portrait 9:16, the platform letterboxes them with white bars or crops them unpredictably.

    This matters because most design tools—Canva, Figma, Keynote—default to landscape aspect ratios for presentation decks. You can spend an hour building a carousel in 1920×1080, upload it to LinkedIn, and watch it get squashed into a square with your text pushed to the edges or cut off entirely.

    Why LinkedIn forces square slides

    LinkedIn’s document post feature converts uploaded PDFs into image carousels optimised for mobile feeds. The platform standardises everything to 1080×1080 because square posts take up more vertical real estate in the feed and perform better on mobile screens.

    The conversion happens server-side. You upload a PDF, LinkedIn rasterises each page, and crops or pads to square. There’s no setting to change this. The upload interface accepts PDFs up to 100 MB and 300 pages, but the output format is non-negotiable.

    Design in square from the start

    The simplest fix: build your carousel slides at 1080×1080 pixels before you write a single word.

    In Canva, create a custom design and set dimensions to 1080×1080 px (or use the Instagram Post preset, which defaults to square). In Figma, create a 1080×1080 frame. In Keynote or PowerPoint, set slide size to custom dimensions: 1080 width, 1080 height, with units in pixels.

    This forces you to think vertically. Text blocks need tighter line lengths. Charts and graphs need larger fonts. Horizontally-oriented infographics won’t fit—you’ll need to stack elements instead of spreading them left-to-right.

    Square slides also change how you use whitespace. In widescreen decks, you can balance a headline on the left with a visual on the right. In square format, that same layout feels cramped. Center-aligned, single-focus slides work better.

    If you’ve already built slides in widescreen

    You have three options, none of them fast.

    Option one: Rebuild from scratch. Copy your text into a new square template and reposition every element. Time-consuming, but you’ll avoid cropping issues.

    Option two: Export widescreen slides as images, then embed them in a square PDF. Create a 1080×1080 canvas in Canva or Figma, place your 1920×1080 slide image in the center, and export each page as a PDF. This preserves your original layout but adds letterboxing (black or white bars above and below). It works if your design can tolerate the padding, but it wastes vertical space.

    Option three: Crop strategically. If your widescreen slides have a clear focal point, you can manually crop each one to 1080×1080 in an image editor, keeping the most important content centered. This only works if your text and visuals are already concentrated in the middle third of the slide.

    Non-obvious tip: Use safe zones

    Even when you design in square, LinkedIn’s mobile app crops the top and bottom of carousel slides slightly when they appear in-feed. Users see the full square only after they tap to expand.

    To avoid cut-off text, keep critical content—headlines, CTAs, key data points—within a centered 1080×920 pixel safe zone. That’s roughly 80 pixels of padding on top and bottom.

    In Canva, add a rectangle guide at 1080×920, center it, and design inside that boundary. In Figma, create a nested frame. This ensures your most important content is visible even before someone taps through.

    One more detail: LinkedIn compresses uploaded PDFs. If you’re using gradients, subtle shadows, or fine typography, export your PDF at high quality (300 DPI if your tool supports it) to minimize artifacting. The platform will still compress it, but starting with a high-resolution source reduces quality loss.

    Hit reply and tell us: what’s one LinkedIn carousel design mistake you made that you won’t repeat? We read every response.

  • ConvertKit broadcast analytics: open rate vs. link click timing lag

    ConvertKit broadcast analytics: open rate vs. link click timing lag

    ConvertKit broadcast analytics: open rate vs. link click timing lag
    Photo by Kit (formerly ConvertKit) on Unsplash

    ConvertKit’s broadcast analytics dashboard updates in real time—sort of. Opens appear within minutes of sending. Link clicks take longer. Sometimes hours longer. If you’ve ever sent a broadcast, refreshed obsessively, and wondered why you’re seeing 400 opens but only 12 clicks an hour later, you’re not imagining things. The delay is real, and it’s not a bug.

    Why opens report faster than clicks

    Email opens are tracked with a tiny invisible image embedded in every message. When a recipient’s email client loads that image, ConvertKit logs an open. Most modern email clients—Gmail, Apple Mail, Outlook—preload images as soon as the email arrives in the inbox, even before the recipient actually opens it. That means ConvertKit sees the open event almost immediately, whether or not anyone’s reading.

    Link clicks are different. They require the recipient to actually click a URL in your email. ConvertKit wraps every link with a tracking redirect, so when someone clicks, the request hits ConvertKit’s servers first, gets logged, then redirects to your destination. That’s a real human action, not a preloaded asset. It takes time—and it only happens if someone’s genuinely engaged.

    The lag isn’t just about recipient behavior. ConvertKit processes click data in batches. Opens are logged instantly because they’re high-volume and low-cost to write. Clicks trigger additional database writes—subscriber activity logs, segment recalculations, automation triggers—so they’re processed in queues. Depending on send volume and server load, that queue can take 15 minutes to two hours to fully flush.

    When the lag matters (and when it doesn’t)

    If you’re sending time-sensitive content—a flash sale, a webinar reminder, a product launch—you need to know whether people are clicking, not just opening. But checking analytics five minutes after send is premature. The first wave of opens will arrive fast. Clicks won’t stabilize for at least 30 minutes, often longer.

    Here’s the timing pattern I’ve seen across dozens of broadcasts to lists between 2,000 and 50,000 subscribers: opens plateau around 60–90 minutes post-send. Clicks plateau around 90–120 minutes. If you’re making a decision—resend to non-openers, adjust your landing page, kill an underperforming link—wait at least two hours. Earlier than that, you’re reading incomplete data.

    One edge case: if you’re using ConvertKit’s link triggers to start an automation (e.g., someone clicks “Download the guide” and gets tagged or moved to a sequence), those triggers fire in real time. The click gets logged for automation purposes immediately, but the analytics dashboard number lags behind. So your automation might run before the dashboard reflects the click. That’s intentional—ConvertKit prioritizes subscriber experience over reporting speed.

    How to read early-stage broadcast data correctly

    Don’t calculate click-through rate in the first hour. The denominator (opens) inflates faster than the numerator (clicks), so your CTR will look artificially low. If you see 8% CTR at the 30-minute mark, it’ll likely settle closer to 12–15% by hour three. I’ve watched this pattern repeat across hundreds of sends.

    Instead, track absolute click volume early on. If you’re expecting 200 clicks based on past performance and you’re seeing 40 after 30 minutes, you’re probably on track. If you’re seeing 4, something’s wrong—your subject line didn’t match your content, your link isn’t visible, or your CTA is buried.

    One non-obvious tactic: compare your current broadcast’s early click volume to a similar past broadcast at the same elapsed time. ConvertKit doesn’t surface this view natively, so keep a simple spreadsheet: broadcast name, list size, clicks at 30 min, clicks at 60 min, final clicks at 24 hours. After five or six sends, you’ll have a reliable benchmark. If today’s 30-minute number is significantly lower than your average, you can troubleshoot before the send is fully delivered.

    When stale data becomes a problem

    The lag compounds if you’re running paid traffic to a landing page mentioned in your broadcast. You send the email, check ConvertKit 20 minutes later, see weak click numbers, panic, and spin up a Facebook ad to the same page. Then the ConvertKit clicks catch up an hour later, your ad spend overlaps with organic email traffic, and you can’t tell which source drove conversions. If you’re mixing email and paid on the same day, give email at least 90 minutes to report fully before you activate paid.

    ConvertKit’s reporting delay is also why A/B subject line tests sometimes feel inconclusive. The platform splits your list, sends both variants, and declares a winner based on open rate after a set window (usually 4 hours). But if clicks are your real goal, the winner might not be the variant with the highest open rate—it’s the one with the best click-through. You won’t know that until hours after ConvertKit has already sent the winning variant to the remainder of your list.

    If click-through matters more than open rate for your business, skip ConvertKit’s built-in A/B test. Manually split your list into two segments, send both variants as separate broadcasts, and wait 3–4 hours to compare click data. It’s more work, but the data’s accurate.

    Got a ConvertKit analytics question we should cover? Reply to this email—we read every one and use reader questions to shape future articles. If you found this useful, forward it to another operator who’s probably refreshing their dashboard right now.

Powered by CookieAdmin