A test call completed successfully by every visible signal — Twilio logged it, billed it, and returned 200 on the status callback — yet the app's primary webhook never fired and no error appeared anywhere. I diagnosed it by cross-referencing three sources: Twilio's Request Inspector (only one webhook dispatched, not two), the app's database (no row created), and Twilio's Debugger (zero logged errors). That narrowed the failure to something happening before the app was ever involved. Confirming through Twilio's REST API showed the account was still in trial mode: trial accounts play an audio message requiring a keypress before dispatching to the voice webhook at all, and the test calls had been too short to trigger it. I verified the fix by sending a properly HMAC-signed synthetic request directly to the production endpoint — isolating the app's own correctness from Twilio's account-level gating before touching anything.

One-off database scripts called dotenv.config() before importing the DB client, expecting sequential execution — but bundler import hoisting ran the DB client's module-level code (which reads process.env) before the config call ever executed, despite the source order looking correct. It manifested as a cryptic LibsqlError: URL_INVALID with no obvious connection to environment loading. I fixed it by using Node's native --env-file flag to load environment variables before the module graph evaluates at all — sidestepping the ordering issue entirely rather than patching around it.

A production phone number was found attached to a stale test workspace left over from earlier development — invisible from the live account because workspace scoping correctly hid it. I diagnosed it with a direct read-only query script against the production database, then fixed it with a small reassignment script rather than manual SQL, keeping the change scripted and reviewable.