Cómo evitar que Supabase pause tu web: el despertador que montamos para que no pase

Nov 2026

Supabase pausa los proyectos gratis tras una semana con poca actividad y Upstash los archiva a los catorce días. Nos pasó con Polish, nuestro coach de idiomas. Así montamos un despertador que lo evita, sin pagar nada.

Si tu web usa una base de datos en un plan gratuito, puede dejar de funcionar sin que nadie la toque. Supabase pausa los proyectos del plan Free cuando la base no recibe actividad suficiente durante una semana, y Upstash archiva sus bases Redis gratis tras catorce días sin uso. La web sigue cargando, pero el login, los datos y todo lo que depende de la base dejan de responder. Nos pasó el 4 de noviembre de 2026 con Polish, nuestro coach de idiomas, y lo resolvimos con un despertador: un script que toca cada base dos veces por día y avisa si algo no contesta. Te contamos qué pasa exactamente, cómo lo armamos y qué conviene revisar en tu propia web.

El síntoma engaña. Polish está en Vercel y la página cargaba perfecta: diseño, textos, botones. Pero al entrar con Google no pasaba nada, y en la consola del navegador el dominio de la base de datos ni siquiera resolvía. Supabase había pausado el proyecto por falta de actividad, tal como dice su documentación: si en la última semana la base recibe poco uso, la duermen. Avisan por correo una semana antes y otra vez cuando la pausan, pero esos correos llegan a la cuenta dueña del proyecto, que no siempre es la que miras todos los días. Reanudarlo desde el panel tardó unos cuatro minutos y no se perdió nada: Supabase conserva los datos y la configuración, y deja restaurar un proyecto pausado hasta un año después.

No es un fallo ni una trampa: es el trato del plan gratis. Supabase regala dos proyectos por cuenta y, a cambio, apaga los que no se usan para no gastar servidores en bases vacías. Upstash hace algo parecido con Redis: según sus preguntas frecuentes, tras un mínimo de catorce días sin actividad archiva la base (guarda una copia y retira la instancia), y para volver hay que crear una base nueva y cargar esa copia desde su consola. Para un producto con usuarios todos los días esto no pasa nunca. Pasa con lo que vive en los bordes: una demo que le mostraste a un cliente hace tres semanas, una app interna que se usa a rachas, un prototipo que vas a retomar "el mes que viene". Justo lo que una agencia acumula sin darse cuenta.

Teníamos cinco bases en esa situación: las de Polish, Temprofit y el inventario de una cafetería cliente en Supabase, y dos Redis de Upstash que guardan contadores de visitas y tarjetas de socio. Pagar un plan de pago por cada una no tenía sentido para proyectos que facturan poco o nada. Lo que hicimos fue un despertador: un script de cien líneas en bash que corre en GitHub Actions dos veces por día, hace una consulta mínima a cada base y, de paso, comprueba que trece webs y servicios nuestros respondan. Si todo está bien, la corrida termina en verde en menos de medio minuto. Si algo falla, termina en rojo y GitHub manda un correo. Cuesta cero: los minutos gratis de GitHub Actions sobran para esto.

Elige consultas que no cambien nada Cada toque es una lectura inofensiva: pedir un perfil con la clave pública (sin sesión, la base devuelve una lista vacía) o leer el contador de visitas de un sitio que no existe. Nada escribe, nada toca datos de nadie. Para contar como actividad alcanza con que la base reciba la consulta.
Usa solo claves públicas El script lleva las mismas claves públicas (anon) que ya van en el código de cada web, guardadas como secrets del repositorio. Dos de nuestras bases no dejan leer ninguna tabla con esa clave, y así tiene que ser, por eso les creamos una función SQL de una línea que solo devuelve la hora. Es la única puerta que abre, y no muestra nada.
Reintenta antes de gritar Un tropiezo de red a las siete de la mañana no es una caída. Cada comprobación lo intenta hasta tres veces, con 15 y 30 segundos de espera, antes de marcar fallo. Así el correo de alerta solo llega cuando de verdad hay algo.
No lo programes a la hora en punto GitHub a veces descarta corridas programadas cuando está cargado, sobre todo a las horas en punto. El nuestro corre a las 07:23 y a las 18:47, hora de Madrid. El primer despertador que armamos, de una corrida diaria, se saltó una el primer día: por eso ahora son dos por día y no una, y por eso conviene que el aviso de Supabase llegue con una semana de margen.
Deja que el rojo te avise Lo importante no es el verde de cada día, es el correo cuando algo falla. Nosotros sumamos a la lista la propia tresojotas.com, el servicio que genera los PDF de las facturas de Temprofit y las webs de clientes que mantenemos: dieciocho comprobaciones en total. Si una base se pausa igual, nos enteramos ese mismo día, no cuando un usuario escribe.

Si tu web la hizo alguien hace meses y "funciona sola", vale la pena hacerse tres preguntas. ¿Dónde está la base de datos y en qué plan? ¿A qué correo llegan los avisos de ese proveedor, y lo lee alguien? ¿Qué pasa si esa base se apaga: la web muestra un error claro o parece que funciona, como nos pasó a nosotros? Una web que carga pero no deja entrar es peor que una caída franca, porque nadie avisa. Y si la respuesta a la primera pregunta es "ni idea", ese es el lugar por donde empezar.

Resumido: el plan gratis es un trato, no un regalo, y el trato incluye que te apaguen lo que no usas. Un despertador de cien líneas lo cumple por ti: una lectura inofensiva dos veces al día, con claves públicas, reintentos y un correo cuando algo se rompe. Lo tenemos en marcha desde el 5 de noviembre de 2026 para todo lo que tenemos en planes gratuitos (demos, prototipos y productos propios), y es el tipo de cosa que preferimos resolver antes de que un cliente la descubra por nosotros. Si tienes una web o un prototipo en esa situación y no sabes en qué estado está, cuéntanos y lo miramos.