Registros: compilaciones y solicitudes de tu sitio
Los registros te dicen qué pasó y cuándo: cada compilación y publicación del proyecto, y cada solicitud que ejecutó el código propio de tu sitio en el último día. Úsalos para averiguar por qué un formulario, una tarea programada o una página no se comporta bien.
Dos tipos de registro
| Ver | Qué muestra | Hasta cuándo hacia atrás |
|---|---|---|
| Builds | Cada construcción, cambio y publicación de este proyecto, y los pasos por los que pasó cada uno. | Las últimas 40 |
| Requests | Las solicitudes y los errores del sitio, de más reciente a más antiguo. | Las últimas 24 horas, hasta 100 a la vez |
Las tareas programadas y los webhooks guardan sus propios registros durante treinta días: Runs en Tareas programadas y Deliveries en Webhooks. Los mensajes enviados a través de tus formularios se guardan en Settings, Forms.
Builds
Cada entrada indica qué se pidió (con las palabras de la solicitud), quién lo pidió, cuándo y cuánto tardó. Cuando no lo inició una persona, aparece Briks. A la derecha está su estado:
| Estado | Significado |
|---|---|
| Waiting | En cola tras otras tareas. |
| Running | En marcha ahora. |
| Done | Terminado. |
| Failed | Se detuvo antes del final. |
| Stopped | Se detuvo antes de terminar. |
Haz clic en una entrada para ver sus pasos, cada uno con la hora a la que ocurrió. Un paso que salió mal aparece en rojo. Una entrada fallida termina con: It did not finish. Nothing on the live site changed, and no credits were charged for it.
Para ver el mismo trabajo mientras ocurre, con la vista previa al lado, usa el estudio: consulta Cómo seguir una creación.
Solicitudes
Requests muestra las llamadas que ejecutaron el código propio de tu sitio: sus rutas /api y las visitas a páginas mientras una prueba A/B reparte a los visitantes entre dos versiones. Las páginas normales, las imágenes y los archivos se sirven tal cual, así que no aparecen. Tampoco aparecen los mensajes enviados con un formulario de contacto, que van directamente a Briks y no pasan por el código de tu sitio.
Cada línea muestra la hora, el método y la ruta (GET pide algo, POST envía algo), cuánto tardó en milisegundos y el estado con el que respondió el sitio, o sin respuesta. Las líneas que escribió el propio código de tu sitio muestran su mensaje y un nivel como error o warning. Haz clic en una línea para ver el mensaje completo, la fecha y el id de la solicitud.
| Estado | Qué significa |
|---|---|
| 2xx, como 200 | Funcionó. |
| 4xx, como 400 o 404 | Se rechazó la solicitud: faltaba algo o había algo incorrecto, o no existe nada en esa ruta. |
| 5xx, como 500 | El código del sitio falló al responder. |
Filtros
| Filtrar | Opciones | Úsalo para |
|---|---|---|
| Search | Cualquier texto: una ruta, un mensaje, un id de solicitud | Encuentra una ruta o un error. |
| Level | All levels, Errors, Warnings | Muestra solo los problemas que informó el código. |
| Status | Any status, Succeeded, 4xx, 5xx | Muestra solo las solicitudes que se rechazaron o fallaron. |
Configúralos y pulsa Show. La dirección de la página los conserva, así que puedes guardar una vista filtrada como marcador. No requests in the last day significa que nada ejecutó el código del sitio en 24 horas. Si la página dice Logs cannot be read right now, inténtalo de nuevo en un minuto.
Diagnostica un formulario que falla
Busca la entrada
Dónde: Settings, Forms
Aquí se guarda cada mensaje que envía un visitante, y se muestran los últimos 100. Cada uno indica cuándo llegó y desde qué página, y después emailed, not emailed o preview.
Si dice vista previa
Dónde: Settings, Forms
El sitio no se ha publicado en producción, así que las entradas se conservan, pero no se envían por correo. Consulta Publicar en producción.
Si dice enviado por correo pero no llegó nada
Dónde: Your inbox
Las entradas llegan a la persona que creó el proyecto o, si esa persona se ha ido, al primer Owner del espacio de trabajo. Revisa esa bandeja de entrada, incluida la carpeta de spam.
Si no aparece en absoluto
Dónde: The live site
El mensaje nunca llegó a Briks. Envía uno tú mismo. Si el formulario responde que se enviaron demasiados mensajes desde aquí, se alcanzó un límite: hasta 5 mensajes por visitante en 10 minutos y hasta 300 al día para el sitio.
Si otra herramienta debe tenerlo
Dónde: Settings, Webhooks, Deliveries
Pon Status en Failed y pulsa Show. Abre el envío para leer lo que respondió la otra herramienta y, cuando lo hayas corregido, pulsa Send again.
Diagnostica una tarea programada que falla
Lee la ejecución
Dónde: Settings, Scheduled tasks, Runs
Abre la ejecución fallida. Muestra lo que respondió la dirección, por ejemplo respondió 500, y el comienzo de la respuesta.
Encuentra el error
Dónde: Settings, Logs, Requests
Si la tarea llama a una ruta de tu sitio, busca su ruta, por ejemplo
/api/daily-summary, y establece Level en Errors. El mensaje indica qué falló en el código.Pide la corrección
Dónde: Studio
Pega el error en el chat del estudio con una frase sobre la tarea: La ruta del resumen diario falla con este error cada mañana. Consulta Hacer cambios.
Inténtalo de nuevo
Dónde: Settings, Scheduled tasks
Cuando la corrección esté publicada, abre los tres puntos de la tarea y elige Run now. El resultado aparece al instante.
Una ejecución marcada como Skipped no falló: se agotaron las llamadas del proyecto para el día. Las ejecuciones vuelven a empezar después de medianoche UTC. Los límites de los planes están en la página Tareas programadas.
Diagnosticar una página lenta
Requests mide todo lo que ejecuta el código de tu sitio, así que es el lugar donde mirar cuando una página que carga su contenido desde las rutas del sitio va lenta. Las apps y los dashboards suelen funcionar así.
Abre la página y anota la hora
Dónde: The live site
Carga tú mismo la página lenta una vez, para que sus solicitudes estén entre las más recientes.
Lee los tiempos
Dónde: Settings, Logs, Requests
Mira los milisegundos junto a cada solicitud hecha en ese momento. Una ruta que tarda varios segundos mientras otras tardan unos cientos de milisegundos es la culpable.
Acota la búsqueda
Dónde: Settings, Logs, Requests
Busca la ruta de esa página para ver si siempre es lenta o solo a veces, y si junto a ella aparecen Warnings o Errors.
Pide una corrección
Dónde: Studio
Dile al estudio qué ruta es lenta y cuánto, junto con la página a la que sirve.
Si no aparece nada lento, el retraso no está en el código de tu sitio. Las páginas, las imágenes y los archivos se sirven tal cual, así que revisa lo que lleva la página, como imágenes grandes o un vídeo, y describe en el estudio lo que te parece lento.
Ejemplo práctico: una app de reservas que dejó de guardar
No había llegado ninguna reserva nueva desde la mañana, aunque el teléfono no paraba de sonar con gente que decía que el formulario no hacía nada.
En Requests, con Status en 5xx, cada POST /api/bookings desde las 9:12 respondió con un 500. La línea de error junto a ellos decía que faltaba un campo obligatorio.
Desde esta mañana todas las reservas fallan con un 500 en /api/bookings. El registro dice que falta el campo del tamaño de la mascota. Ayer quitamos ese campo del formulario.
El cambio se publicó y la siguiente reserva en Requests respondió 200.