para aplicaciones construidas con Lovable
Tu aplicación no tiene servidor. Igual tiene fallos.
Todo lo que hace tu aplicación ocurre en dos sitios que una herramienta de monitorización normal no puede ver: el navegador y Supabase. Sixty mide los dos desde dentro de la página — las consultas y lo que devuelven, los canales en tiempo real, qué pulsó la gente y si funcionó, y lo rápido que fue todo ello —, compara cada publicación con la anterior y entrega lo que encuentra al agente que escribió el código.
Qué mide
- Cada consulta a Supabase que hace la página
- Cuántas se ejecutan por interacción, cuántas filas devuelve cada una, cuál es el tamaño de la respuesta y cuánto tardó. Aquí es donde casi siempre acaba estando el «se volvió lento».
- Lo rápida que es la página, por ruta
- LCP, INP, CLS y TTFB en el p75 real de toda la gente que la cargó — no una puntuación de laboratorio desde una máquina. Desglosado por país, porque una página que a ti te va bien puede ser inusable donde la latencia es peor.
- Qué pulsó la gente, y si funcionó
- Clics que no hicieron nada, clics repetidos sobre el mismo control, e interacciones que redibujan la página cientos de veces.
- Auth, almacenamiento, funciones edge y tiempo real
- Una aplicación de Supabase son cuatro servicios, no uno, y el agente entiende qué hace cada endpoint y no solo cuánto costó — así que un inicio de sesión rechazado, una columna que falta, una escritura denegada y un canal que no logró suscribirse llegan cada uno como lo que son, en vez de como una petición fallida anónima.
- El código, antes de ejecutarse
- Un botón sin manejador, un efecto cuyas dependencias garantizan que se repetirá para siempre, una suscripción que nunca se cierra. Estos no emiten nada en tiempo de ejecución — un manejador que nunca se enganchó no se puede medir —, así que se leen del código fuente al compilar y se ordenan por el tráfico que realmente recibe el archivo.
Qué encuentra
Cada una de estas se compara con la versión anterior, así que el hallazgo nombra el cambio y no el día.
Una consulta que empezó a devolverlo todo
Un filtro desaparece en una reescritura y una consulta que devolvía 30 filas devuelve 30.000. Contra el puñado de filas de tu proyecto es instantánea, así que nada parece ir mal hasta que hay datos de verdad detrás.
Un N+1 nacido dentro de un render
Una petición se mete dentro de una lista y una consulta se convierte en cuarenta. Cada una es rápida, así que ninguna petición individual parece mal — lo único que está mal es el número, y el número es justo lo que no te enseñará nada más que puedas instalar.
Usuarios viendo las filas de otros — o las de nadie
Cuando una política de seguridad a nivel de fila falta o está mal, Postgres no lanza ningún error. Devuelve filas que no deberían estar ahí, o ninguna, y la página se renderiza en blanco. Sixty ve las dos mitades: las sentencias que la base de datos rechaza bajo una política, y las que permite y vuelven vacías donde antes volvían llenas.
Una página que nunca termina de cargar
Un indicador de carga todavía en pantalla doce segundos después de aparecer — normalmente una petición que falló dentro de un catch, o una bandera de carga puesta a true y nunca devuelta.
El esquema separándose del código
Una columna, tabla o relación que el código espera y la base de datos ya no tiene. Falla en tiempo de ejecución, en el navegador, sobre quien haya cargado esa página.
Errores que nadie reportó
Agrupados por el punto del código del que salieron, incluidos los fallos de React que no rompen nada — el error boundary los captura, muestra un área en blanco y los registra.
El mismo canal de tiempo real, suscrito tres veces
Un efecto abre una suscripción y nunca la cierra, así que cada render añade otra. No salta nada y nada va lento: la persona simplemente ve llegar cada mensaje nuevo tres veces, mientras el número de conexiones sube hacia el límite que apagará la función para todo el mundo.
Un botón que, medido, no hace nada
Pulsado, y no salió ninguna petición, no cambió ningún dato, no se movió ninguna página — normalmente un manejador que nunca se conectó. Más los clics repetidos que vienen después, que es lo que hace la gente cuando el primero pareció no hacer nada.
Un clic redibujando la página cientos de veces
Un bucle de render. Nunca da error y nunca hace fallar una petición; le vacía la batería a quien tiene el teléfono en la mano.
Sesiones siendo rechazadas
Una parte de las llamadas a un endpoint volviendo con 401 o 403, o un token caducado donde hacía falta uno. En una aplicación sin servidor, este es el único sitio donde un rechazo es visible.
Qué aparece en tu lista
No es un panel que leer. Una tarjeta por hallazgo, con las cifras, la versión que las cambió y las pruebas que tu agente de código necesita para escribir el arreglo.
Reconstruido. Estos son fallos que el detector produce de verdad en una aplicación de Supabase publicada — pero, a diferencia de los ejemplos de Node, no son la salida de un script que puedas ejecutar, así que están dibujados en lugar de citados.
select:ordersEsta consulta devuelve todos los pedidos de la tabla y los filtra en el navegador. Se escribió contra un proyecto con cuarenta filas, donde eso era instantáneo.
en /orders, desde la penúltima publicación
select:invoicesLa misma consulta que ayer devolvía facturas hoy no devuelve ninguna. Nada falló: una política empezó a filtrarlo todo, y la página se renderiza en blanco.
en /invoices, desde la última publicación
Cómo se instala
Esto no se instala a mano. Pega un prompt en el chat de Lovable y él conecta el agente — un plugin de Vite, una llamada de inicialización y una ruta que reenvía la telemetría para que ninguna clave llegue nunca a tu bundle. Al iniciar sesión, ese prompt se escribe por ti con tu clave ya dentro.
npm install @sixty-sh/supabase
// vite.config.ts
import drift from '@sixty-sh/supabase/vite'
export default defineConfig({ plugins: [react(), drift()] })
// src/integrations/supabase/client.ts — the file every Lovable app has
import { withSixty } from '@sixty-sh/supabase'
export const supabase = withSixty(createClient(URL, ANON_KEY), {
key: 'sixty_pk_…',
service: 'my-app',
endpoint: 'https://ingest.sixty.sh',
})Después publica dos veces. La comparación está anclada a las publicaciones y no al reloj, así que el primer hallazgo llega tras la siguiente — no hay nada con lo que comparar una única versión.
Qué no hace
- Los hallazgos de una build publicada apuntan a la consulta y a la ruta, no a una línea de tu código. Los bundles de producción están minificados y el sourcemap que desharía eso todavía no se lee, así que obtienes «esta consulta en esta página» en vez de «este archivo, línea 40».
- La vista previa de Lovable no basta. Corre un servidor de desarrollo sin recursos con huella, así que no hay ninguna versión a la que anclar una comparación — la comparación necesita dos publicaciones reales.
- Aquí no se vigila ningún servidor, porque no tienes uno. Si más adelante añades funciones edge propias, necesitan el agente de Node para ser visibles.
Si estás aquí por una de estas
Descubre qué hizo tu último cambio.
¡Pruébalo!¿Construyes otra cosa? Mira servicios Node o aplicaciones React Native — esas páginas son distintas, y también lo es lo que podemos ver.