Our Blog Was Dark for 12 Days: The Firebase App Hosting Deploy Gap Nobody Warns You About
Our deploy automation reported success every single morning while the site served an 11-day-old build. The bug wasn't in the code — it was in what we chose to verify.
Our deploy automation reported success every single morning while the site served an 11-day-old build. The bug wasn't in the code — it was in what we chose to verify. In this deep dive, we explore actionable strategies, real-world engineering blueprints, and future-proof patterns to elevate your digital operations.
Our blog deploy automation ran at 8:00 AM every morning. It regenerated posts from our content vault, committed the changes, pushed to the remote, and exited with code 0. Silent success. No alerts, no errors, nothing to investigate.
Meanwhile the live site had been serving a build from twelve days earlier.
Two published articles returned "Blog Post Not Found." A lead-capture API endpoint returned 404 to every visitor. The automation never once complained, because from its point of view nothing had gone wrong.
The Assumption That Broke Everything
The pipeline had a comment in it that turned out to be the entire bug:
# Commit + push (triggers Firebase App Hosting deploy)
That parenthetical was doing a lot of load-bearing work. It was also wrong.
Firebase App Hosting supports automatic rollouts when you push to the live branch of a connected GitHub repository. Our origin is Bitbucket. App Hosting has no Bitbucket integration — you cannot connect one through the console, and the CLI will tell you so if you ask it directly:
Backend is missing a connected repository. If you would like to deploy from a branch or commit of a GitHub repository, you can connect one through the Firebase Console.
So git push was working perfectly. Commits landed. The remote updated. And absolutely nothing deployed, because there was no listener on the other end. The push went into a repository that the hosting platform had never heard of.
Why It Stayed Hidden So Long
This class of bug survives because every individual step genuinely succeeds.
The content generator ran and wrote correct output. Git staged, committed, and pushed without error. The script checked exit codes at every stage and all of them were zero. The automation then wrote its own state file recording the posts as deployed, and used that state file on subsequent runs to decide there was nothing new to do.
That last part is what turned a one-day outage into a twelve-day one. The script marked the work as finished before confirming the work had any effect. Every following run read that state, concluded the posts were already handled, and stayed quiet — exactly as designed.
The automation was measuring its own effort, not its outcome.
The Fix, In Two Parts
First, deploy explicitly instead of hoping a trigger fires. App Hosting accepts a local-source deploy that uploads your build directly and starts a rollout, no repository connection required. That replaces the imaginary push-triggered deploy with a real one we control.
Second — and this is the part that actually matters — verify from the outside. The pipeline now fetches each published URL over the public internet after deploying and checks the response body before recording anything as deployed.
The body check is not optional, and this caught us out. Requesting a slug that doesn't exist on a Next.js site returns HTTP 200 with a rendered not-found page. A status-code check alone passes happily on a page that says "Blog Post Not Found" to every human who visits it. You have to read what was actually served.
If verification fails, the state file is left untouched and an alert goes out. The run reports failure. Tomorrow's run tries again instead of assuming yesterday's phantom success.
The Lesson Worth Keeping
Every step in that pipeline succeeded. The pipeline still failed completely.
Automation that reports on its own actions will tell you it pushed, it committed, it exited clean. Automation that reports on observable results tells you whether a reader can load the page. Those are different systems, and only one of them is worth trusting with something you can't see.
If you have a deploy pipeline you've never independently verified, go load the live URL right now and read what comes back. Not the status code — the actual content. We assumed ours worked for twelve days on the strength of a comment in a Python script.
Check the ones that report success most reliably. Those are the ones nobody looks at.
FAQ
Related Reading
- Hire a React Developer in India: What to Look For and What to Avoid
- Next.js vs WordPress for Enterprise: The Decision Framework That Actually Makes Sense
- Custom Web Development in Chennai: What You're Actually Paying For
- Why Your Website Is Slow (And What It's Costing You)
- AI-Powered Web Development in 2026: What Actually Changed
Why doesn't git push deploy to Firebase App Hosting?
Firebase App Hosting only triggers automatic rollouts from a connected GitHub repository. If your git origin is Bitbucket, GitLab, or any self-hosted remote, App Hosting has no integration to listen on, so the push succeeds and nothing deploys. You must run an explicit local-source deploy instead: npm run build followed by firebase deploy --only apphosting --project YOUR_PROJECT.
Can Firebase App Hosting connect to Bitbucket?
No. As of 2026 App Hosting supports GitHub only for repository connections. The Firebase CLI states this directly if you attempt a branch rollout: "Backend is missing a connected repository." Your options are an explicit CLI deploy from local source, or mirroring the repository to GitHub.
Why does my deploy script report success when nothing deployed?
Because it is checking its own actions rather than the observable outcome. Every individual step (generate, stage, commit, push) genuinely succeeds and returns exit code 0. Nothing in that chain verifies that a reader can load the page. Fix it by fetching the public URL after deploying and inspecting the response body before recording anything as complete.
Does an HTTP 200 response mean my page is working?
No. A Next.js site returns HTTP 200 along with a fully rendered "not found" page when the slug does not exist. A status-code-only health check passes happily while every visitor sees an error. Always inspect the response body for a positive signal, such as the expected page title.
How do I stop a deploy pipeline from hiding failures?
Never write "done" state before verifying the result externally. Our script saved its deployed-state file and exited 0, so every subsequent run read that state, concluded there was nothing to do, and stayed silent. One day of outage became twelve. Save state only after an external check confirms the change is live.
Deploying to App Hosting and hitting the same wall? Message me on WhatsApp or work with us.
Get more insights like this
Join our list for practical automation, web engineering, and growth strategy — written by builders, for builders.
Manikandan S
Founder & Technical Lead at ZiyncFounder and technical lead at Ziync. I build high-performance websites and web applications for startups and mid-market teams: React, Next.js, Firebase. Based in Chennai, working with clients worldwide.