The Deploy That Broke Everything (Three Times)

How a stale /tmp/ directory silently wiped our Meta Pixel, served the wrong landing page to Windows users, and sent old OG cards to every social platform - all while we thought everything was fine.

I deployed the Push to Transcribe website over 20 times during our marketing launch. Three of those deploys silently broke critical things. Nobody noticed until real money was being wasted.

The root cause was the same every time: a temp directory that survived between deploys. And the fix was embarrassingly simple once I found it. But finding it took days, because every deploy looked successful.

Break #1: The Meta Pixel Vanished

We were running Facebook ads. $13 in spend, 42 clicks, $0.31 per click. The metrics in Ads Manager looked reasonable. But the Meta Pixel on our landing page had stopped firing.

The Pixel tracks what happens after someone clicks an ad - did they visit the page, did they download, did they bounce. Without it, Facebook’s optimization algorithm has no signal. It’s spending your money blind.

The Pixel was in our HTML. I’d verified it. But after a deploy, it was gone from the live page. The wrangler deploy succeeded. Cloudflare Pages showed the new version. But the actual served HTML was missing the fbq('init') snippet.

What happened: our deploy script built the site into /tmp/ptt-deploy/. The previous build’s files were still sitting there from the last deploy. The new build partially overwrote them - some files got updated, others didn’t. The index.html that got uploaded was a stale copy from a previous build that predated the Pixel integration.

The deploy reported success because wrangler uploaded everything in the directory. It just uploaded the wrong version of some files.

Break #2: Windows Users Saw “Coming Soon”

This one was worse because it was customer-facing during an ad campaign.

We’d built platform-specific download pages. Mac users see the Mac download button. Windows users see a “Coming Soon - Join the Waitlist” message (Push to Transcribe was Mac-only at the time). After a deploy, the Windows page reverted to an old version that showed completely wrong messaging.

Same root cause. The /tmp/ptt-deploy/ directory had a stale windows.html from before we’d written the “Coming Soon” copy. The new build generated the correct file, but the stale file in /tmp/ took precedence because the build tool didn’t clean the output directory first.

We were paying for Facebook clicks that sent Windows users to a broken page. By the time I noticed, the ads had been running for hours.

Every time someone shares a link on Twitter, LinkedIn, or Facebook, the platform scrapes the OG (Open Graph) meta tags from the page to build the preview card - the image, title, and description that appear in the post.

After a deploy, every social share of pushtotranscribe.com was showing an old OG card - wrong image, wrong description. The HTML had the correct og:image and og:title tags, but the actual image file being served was stale.

This time it wasn’t /tmp/ - it was an image_hash vs image_url problem in the Facebook Ads API. We’d been fighting for days to get Facebook to accept our OG card image. Facebook caches OG images aggressively, and once it scrapes the wrong one, clearing it requires the Facebook Sharing Debugger and sometimes just waiting.

But the underlying issue was still the stale build directory. The OG image file in /tmp/ptt-deploy/ was from a previous build, and because wrangler deployed whatever was in that directory, the wrong image went live.

The Root Cause

All three breaks shared one root cause: the deploy directory was /tmp/ptt-deploy/, and nobody was cleaning it between builds.

/tmp/ on macOS doesn’t get wiped on reboot the way you might expect. Files can persist for days. Each build partially overwrote the directory, but files that weren’t regenerated by the new build survived from previous builds. The deploy tool (wrangler pages deploy) uploads everything in the target directory - it doesn’t know which files are fresh and which are stale.

The fix was two lines:

rm -rf /tmp/ptt-deploy/*
# ...then run the build

Clean the output directory before every build. That’s it.

The Deploy Checklist

After the third break, I stopped trusting deploys and wrote a verification checklist:

Clean the build directory - rm -rf the output dir before building
Verify the Pixel - after deploy, open the live page, check the browser console for fbq calls
Check platform pages - load the Windows and Mac pages separately, verify correct messaging
Scrape OG tags - run the URL through Facebook’s Sharing Debugger and Twitter’s Card Validator
Diff the deployed files - compare the uploaded file list against the expected file list

Steps 2-4 take about 90 seconds total. That’s 90 seconds that would have saved hours of wasted ad spend and broken user experiences.

What I Learned

Silent failures are worse than loud ones. All three breaks reported successful deploys. No error, no warning, no diff. The build succeeded. The upload succeeded. The wrong files were served. The only way to catch it was to verify the output after deployment, which I wasn’t doing.

Temp directories are not build directories. /tmp/ is convenient for throwaway work. It’s terrible for anything you’re deploying to production. Files persist across builds, across sessions, sometimes across reboots. If your deploy directory isn’t cleaned before every build, you’re deploying a blend of old and new files.

Verify what you shipped, not what you built. The build was correct. The deploy directory was wrong. The live site was wrong. If I’d checked the live site instead of trusting the build log, I’d have caught each break in minutes instead of hours.