Any setting you fix in a dashboard and not in the repo is a setting you will fix again.
Monday night I moved a client's marketplace off a backend nobody on their side controlled and onto one they actually own. Sync worker down at 7:29pm. Export restored by 7:53 with 41 users, 72,219 listings, and 14 auctions intact. DNS flipped at 8:08, live at 8:09. Called it done at 8:31. About an hour of real downtime risk after weeks of rehearsal on a staging copy. That is the ratio you want.
The cutover was the boring part. The interesting part was the ten minutes after.
Three edge functions that get called by database triggers and cron jobs had JWT verification on by default in the new project. The gateway rejected them, and we dropped eight listing contact notifications before I caught it. The fix took two minutes. But the real fix was adding those three functions to the checked-in config file. Because the next deploy script run would have quietly flipped them right back.
That is the whole lesson. A dashboard toggle you fix by hand is not fixed. It is fixed until the next deploy, and then you are on the phone again wondering why the same thing broke twice.
We hit the same shape on the hosting side. Git-triggered deploys were getting blocked because the client's in-house builder was not linked to a team member on the hosting provider. Nothing to do with code. I burned time on an empty commit as a workaround before we found the account setting.
When a deploy fails, check identity and permissions before you check your build. And when you fix a setting, fix it where the machine reads it, not where a human clicks it.
Any setting you fix in a dashboard and not in the repo is a setting you will fix again.
AI Diagnostic | All insights