Cómo evitar facturas sorpresa en Firebase: una checklist

Firebase tiene una página llamada Avoid surprise bills. Es un buen punto de partida y cubre tres cosas: probar tu código, vigilar tu uso y configurar presupuestos. Abajo tienes lo mismo como checklist, en el mismo orden, con lo que deja abierto cada paso y los pasos que la página no menciona.

Una cosa a tener en cuenta desde el principio: "Firebase pricing plans apply to the entire project, not just to individual apps registered in the project." (los planes de precios de Firebase se aplican a todo el proyecto, no solo a cada app registrada en él). Cada app del proyecto (web, iOS, Android, una build de pruebas apuntando a producción) suma a la misma factura.

Google recomienda la Local Emulator Suite, que ejecuta Firestore, Cloud Functions, Realtime Database y más en tu máquina, para que "you don't incur any Firebase costs that might result from testing against services in production" (no generes costes de Firebase por probar contra los servicios de producción). Mientras pruebas, señala dos patrones a vigilar:

• "Forgetting to add a limit to a database query with millions of results" (olvidar poner un límite a una consulta con millones de resultados)
• "Combinations of Cloud Functions that cause excessive fan-out workloads or even infinite loops" (combinaciones de Cloud Functions que provocan cargas en abanico excesivas o incluso bucles infinitos)

Lo que deja abierto: el emulador muestra lo que hace tu código, no lo que harán con él los usuarios reales o un desconocido. No detecta un listener que se vuelve a suscribir en cada pantalla de la app real, ni un bot llamando a tu función. Para los patrones de lectura que se escapan a las pruebas, mira cómo encontrar qué está leyendo tu Firestore.

El segundo paso de Google: "You need to know what normal usage patterns look like for your app" (necesitas saber cómo es el uso normal de tu app). Cada producto tiene una pestaña Usage en la consola de Firebase, y Settings, Usage and billing muestra todo el proyecto frente a la cuota sin coste.

Dos matices. Los números avanzan a ritmos distintos: "Cloud Firestore and Cloud Storage usage are calculated daily" (el uso de Firestore y Storage se calcula a diario) y "Cloud Functions usage is calculated monthly" (el de Cloud Functions, mensualmente). Y el panel de Firestore es una estimación: "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (el panel no es una vista exacta de las operaciones facturadas, y lo facturado probablemente sea mayor) (documentación de uso de Firestore).

Lo que deja abierto: alguien tiene que mirar. Un panel enseña el pico a quien lo abre, y a las 3 de la mañana nadie lo abre. Si la factura ya es más alta de lo esperado, cómo encontrar qué te está cobrando recorre los informes de facturación hasta el SKU y el día.

Al pasar a Blaze, Firebase te pide crear un presupuesto. Hazlo, pero ten claro qué es: "Budget alerts do not pause services." (las alertas de presupuesto no pausan los servicios). Existen "so that you can take action, if needed" (para que puedas actuar, si hace falta).

Lo que deja abierto: la alerta llega horas después del gasto, y alguien tiene que actuar. El porqué, con las palabras de Google: por qué las alertas de presupuesto no frenan tu factura.

Los presupuestos con spend cap son la opción más nueva: cuando un servicio llega al 100% de su presupuesto, Cloud Billing "pauses that service for the rest of the month" (pausa ese servicio el resto del mes). Solo cubren Firebase AI Logic, App Hosting, Cloud Functions for Firebase y Extensions.

Lo que deja abierto: Firestore, Realtime Database, Cloud Storage y Hosting no están cubiertos. Y Google avisa: "Spend caps are not "hard caps"." (los spend caps no son «límites duros»). La aplicación del límite "can be delayed by several minutes" (puede retrasarse varios minutos), y lo que se gaste en ese intervalo se factura con normalidad.

La página de Google va de vigilar costes. La mayoría de facturas de cinco cifras de nuestras historias de terror vinieron de otro sitio: algo de fuera de la app llamando a servicios de pago. Tres cosas que merece la pena hacer antes de lanzar:

• Restringe tus API keys. Limita cada clave a las APIs y apps que la necesitan, y deja la API de Gemini fuera de cualquier clave que viaje en tu app: cómo restringir una API key de Firebase.
• Activa App Check y reglas de seguridad estrictas. Para que solo tu app llegue a tu base de datos y a tus funciones callable: ataques de denegación de cartera.
• Limita las instancias de tus funciones. Una función desbocada cuesta más cuantas más instancias consigue. Ponle un máximo: cómo limitar el gasto en Firebase.

La página de Google apunta en la misma dirección: sugiere usar las notificaciones de presupuesto para desactivar la facturación del proyecto. Puedes montarlo tú con una función en el topic de Pub/Sub del presupuesto (guía paso a paso), pero lee antes qué pasa cuando se corta la facturación: apaga todos los servicios de pago del proyecto.

O deja que lo haga FireShield. Actúa sobre cada notificación de presupuesto en cuanto llega, puede enviar un webhook de Soft Kill para que tu app se degrade sola antes de cortar la facturación, y en Pro vigila el uso de cada servicio buscando picos, así que un gasto desbocado aparece en menos de una hora y no en el siguiente informe de costes.

1. Prueba en la Local Emulator Suite, con un límite en cada consulta.
2. Conoce tu uso normal por producto, y revísalo tras cada versión.
3. Crea un presupuesto, sabiendo que solo envía alertas.
4. Activa los spend caps en AI Logic, App Hosting, Cloud Functions y Extensions.
5. Restringe las API keys, activa App Check, limita las instancias de las funciones.
6. Conecta algo que actúe sobre el presupuesto sin esperar a una persona.