Skip to main content

Runbook: Functions Deploy Failed

  • Severity: High when it blocks an urgent production fix; otherwise a release-blocking engineering issue.
  • Runtime: Node.js 22.
  • Primary region: europe-west1.

Known blocker (as of 2026-08-16)​

Every Functions deploy currently aborts because APP_STORE_PRIVATE_KEY is not set in Secret Manager for acesense-prod. Check this first — it is the most likely reason you are reading this runbook.

There is no partial path around it. Firebase resolves declared secrets while analysing the whole codebase, so even --only functions:<one-function> fails. A scaler-only deploy was attempted and aborted for exactly this reason.

firebase functions:secrets:set APP_STORE_PRIVATE_KEY --project acesense-prod

The value is the App Store Connect .p8 private key. Consequence worth knowing: the Lambda per-box runtime budget is committed but undeployed, so production still runs the old timeout behaviour until this clears.

Note also that --only functions:NAME aborts regardless — the codebase is named functions, so the filter has to be --only functions.

First response​

  1. Stop retrying the unchanged deployment; preserve the first complete error.
  2. Confirm the intended repository, Firebase project, and authenticated account.
  3. Run the same predeploy gates locally.
  4. Determine whether the failure happened before upload, during build, during Cloud Run/IAM provisioning, or while updating a trigger.
cd acesense-auth-function
pnpm install --frozen-lockfile
pnpm lint
pnpm build
pnpm test
pnpm exec firebase deploy --project acesense-prod --only functions

Common causes​

TypeScript or lint failure​

Fix the first compiler/linter error and rerun all three gates. The Firebase predeploy hook already runs lint and build; bypassing it only moves the failure to runtime.

Wrong Node runtime or stale dependencies​

Verify Node 22 and reinstall from the lockfile. Do not update dependencies as part of incident mitigation unless the lockfile itself is the diagnosed cause.

Missing secret or environment binding​

Compare the function's declared secrets/environment needs with the target project. Store secret values through the platform secret mechanism and redeploy only the affected functions after the binding is present. Never put the value in source or command history.

Credentials, IAM, API, or quota error​

Confirm the deploy identity, required Google APIs, project billing state, and regional quotas. Use Cloud Audit Logs to distinguish a permission denial from a Firebase CLI presentation error.

Existing function cannot be updated​

Inspect runtime, trigger type, region, and codebase. A trigger/region migration can require a staged new function rather than an in-place update. Do not delete a production function until the replacement and its callers are verified.

Mitigation​

If production is healthy, leave the last successful revision serving traffic and fix the candidate offline. If a partial release caused impact, redeploy a reviewed known-good revision from a separate clean worktree and limit the selector to the affected function(s). Record the deployed commit and console revision.

Docs and launchpad have separate function codebases. Their deployable site bundle must be rebuilt/copied before deploying docsServer or launchpadServer; see Deployment.

Verify​

  • Deployment reports success for the intended project/region/codebase.
  • Read-only health or sign-in smoke tests pass.
  • New revision logs contain no startup/import errors.
  • Scheduled/task functions retain their trigger configuration.
  • Auth, Rules, and secret checks still deny an unauthorized request.

Create a postmortem for a production-impacting partial deploy, accidental trigger deletion, or repeated release-system failure.