Por qué las alertas de presupuesto de Firebase no detienen tu factura

Un presupuesto de Firebase o Google Cloud es una alerta, no un límite. Cuando tu gasto supera el 50%, el 90% o el 100% del importe que fijaste, Google envía un email o un mensaje de Pub/Sub, y no pasa nada más: tus lecturas de Firestore, tus funciones y tus descargas siguen funcionando y siguen facturando. Google lo dice claramente en la documentación de Cloud Billing: configurar un presupuesto solo de alertas "doesn't automatically cap Google Cloud or Google Maps Platform usage or spending." (es decir, «no limita automáticamente el uso ni el gasto de Google Cloud o Google Maps Platform»).

La documentación de Firebase lo repite: las alertas de presupuesto "do not cap your usage or charges" («no limitan tu uso ni tus cargos»), son alertas "so that you can take action, if needed" («para que puedas actuar, si es necesario») (planes de precios de Firebase). Alguien tiene que leer la alerta y hacer algo. Ese es el hueco.

Aunque alguien esté atento, la alerta en sí va por detrás del gasto. Google documenta tres retrasos distintos:

• Informe de costes. "There is a delay between your use of Google Cloud resources, and the usage costs reporting to Cloud Billing" («Hay un retraso entre el uso de los recursos de Google Cloud y el momento en que los costes de uso se reportan a Cloud Billing») (documentación de presupuestos).
• Frecuencia de las notificaciones. Las notificaciones de presupuesto llegan a Pub/Sub "multiple times per day" («varias veces al día»), no de forma continua (notificaciones programáticas).
• Cálculo diario del uso. En Firebase, "Cloud Firestore and Cloud Storage usage are calculated daily" («el uso de Cloud Firestore y Cloud Storage se calcula a diario») y "Cloud Functions usage is calculated monthly" («el uso de Cloud Functions se calcula mensualmente») (evitar facturas inesperadas).

En un presupuesto recién creado, Google avisa de que "may take several hours before receiving the first email or Pub/Sub notification" («pueden pasar varias horas hasta recibir el primer email o notificación de Pub/Sub»). Una función atrapada en un bucle o un script machacando tu base de datos no espera tanto.

En 2026 Firebase añadió límites de gasto (spend caps), en versión Preview. Son un avance real, con dos limitaciones que conviene conocer:

• Solo cubren Firebase AI Logic, App Hosting, Cloud Functions for Firebase y Extensions. Firestore, Realtime Database y Cloud Storage no están cubiertos, y es ahí donde ocurren la mayoría de bucles de lectura y avalanchas de descargas.
• La propia Google dice que los límites de gasto "are not 'hard caps'" («no son límites estrictos»): actúan sobre los mismos datos de costes con retraso, y "any cost overages incurred during this delay will be billed as normal." («cualquier exceso de coste generado durante este retraso se facturará con normalidad»).

Actívalos si usas esos productos. Pero no los interpretes como un techo para todo el proyecto.

Algo tiene que actuar sobre la alerta sin esperar a una persona. En la práctica:

1. Dile a tu app que frene. Desactiva funciones caras, pausa los trabajos por lotes o muestra una página de mantenimiento mientras investigas. A esto lo llamamos Soft Kill.
2. Desconecta la facturación como último recurso. Sin cuenta de facturación, Google detiene todos los servicios de pago del proyecto. Funciona incluso si tu código está roto, pero tiene consecuencias que deberías leer antes: qué pasa cuando se detiene la facturación.
3. Detecta el pico antes del informe de costes. Las métricas de uso (lecturas, invocaciones, bytes descargados) aparecen en Cloud Monitoring en cuestión de minutos, mucho antes que el coste.

Puedes construir las dos primeras tú mismo con una función activada por Pub/Sub (consulta el kill switch hecho por ti mismo), o dejar que FireShield las ejecute por ti: escucha las notificaciones de tu presupuesto, ejecuta un Soft Kill o un Hard Kill en los umbrales que elijas y, en Pro, vigila el uso de cada servicio para detectar picos.