Pestaña de errores de la aplicación
Qué hace tu equipo, desde la ficha de la aplicación en UTILIA OS, con los errores que envía tu integración, y qué avisos recibe tu servidor por cada acción.
Actualizado el . 5 min de lectura
Incluido en todos los planes. Ver precios
Cuando tu aplicación envía errores con POST /external/v1/errors/report
o desde el navegador con POST /external/v1/tickets/client-errors, tu
equipo los ve agrupados en la pestaña Errores de la ficha de la
aplicación, en Gestión de proyectos › Aplicaciones externas, necesitas entrar con tu cuenta.
Desde ahí puede investigarlos, silenciarlos, resolverlos, reabrirlos o
convertirlos en un ticket de soporte o en un elemento de trabajo de
Gestión de proyectos.
Esta página explica lo que pasa en ese lado para que sepas qué avisos recibirá tu servidor y cómo encaja todo el circuito de soporte.
Quién usa esta pestaña
Es una pantalla de UTILIA OS para las personas de tu organización, no
algo que tu aplicación muestre a sus usuarios. Verla exige el permiso
EXTERNAL_APPS_ERRORS_VIEW, y actuar sobre los errores,
EXTERNAL_APPS_ERRORS_MANAGE.
Qué muestra
- Estado general: una frase en lenguaje claro y un semáforo (
ok,warning,danger) calculado con los errores activos. Por ejemplo: «3 errores críticos activos sin resolver». - Cifras clave: errores sin resolver, críticos activos, veces que han ocurrido en las últimas 24 horas y variación frente al día anterior, más una tasa de error.
- Últimas 24 horas: un gráfico de barras con un punto por hora, para ver los picos.
- Lista de grupos: un grupo por error, con gravedad, módulo, ruta, número de veces, primera y última vez, estado y enlaces al ticket o al elemento de trabajo si existen.
Estados de un grupo de errores
El estado no se guarda: se calcula cada vez que se consulta.
Estados de un grupo de errores
Activo
active
Cuenta en las cifras y dispara las alertas.Se llega desde Activo cuando: Tu equipo lo silencia de 1 hora a 4 semanas
Silenciado
silenced
Sigue sumando veces, pero no sale en las alertas hasta silencedUntil.
Se llega desde Activo cuando: Tu equipo lo marca como resuelto
Resuelto
resolved
Sale de la lista por defecto. Si vuelve a ocurrir, el contador sube, pero las alertas no vuelven hasta que se reabre.
Otras transiciones
- Silenciado pasa a Activo: Vence el plazo, o tu equipo quita el silencio poniendo 0 horas.
- Resuelto pasa a Activo: Tu equipo pulsa «Reabrir».
Gravedad y semáforo
La gravedad que envía tu aplicación (critical, high, medium, low) decide el color del estado general:
- danger: hay al menos un error
criticalactivo. - warning: hay un pico (en las últimas 24 horas, el doble o más que el día anterior) o errores activos, ninguno crítico.
- ok: ningún error activo.
Qué puede hacer tu equipo
Silenciar
Oculta un grupo de las cifras y alertas durante un periodo de 1 hora a 4
semanas, por ejemplo mientras se investiga. Volver a silenciar
sustituye el plazo anterior, y poner 0 horas quita el silencio antes de
tiempo. Aviso a tu servidor: ERROR_SILENCED, con until (fecha ISO
8601) o null si se quita el silencio.
Resolver
Cierra el grupo, con una nota interna opcional de hasta 2.000
caracteres sobre la causa o la solución. Resolver uno ya resuelto no
cambia nada ni repite el aviso. Aviso: ERROR_RESOLVED, con
resolvedBy y note.
Reabrir
Devuelve un grupo resuelto a active, por ejemplo si la corrección no
funcionó. Aviso: ERROR_REOPENED.
Crear un ticket de soporte
Crea un ticket de categoría BUG a partir del grupo, con la descripción
ya rellena (mensaje, módulo, identificador del grupo y ruta). Tu equipo
puede cambiar el título, la descripción y la prioridad antes de crearlo.
El grupo queda enlazado al ticket y la lista muestra su clave (por
ejemplo, mi-app-0001). Aviso: ERROR_LINKED_TO_TICKET, con
{ ticket: { id, ticketKey } }.
Crear un elemento de trabajo
Crea un elemento de trabajo en Gestión de proyectos (tipo BUG si la
gravedad es alta o crítica; TASK en otro caso) en el proyecto
vinculado a la aplicación. Si la aplicación no tiene proyecto
vinculado, hay que elegirlo al crearlo. El grupo queda enlazado y la
lista muestra su clave (por ejemplo, PROJ-123). Aviso:
ERROR_LINKED_TO_ISSUE, con { issue: { id, key } }.
Varios grupos a la vez
Tu equipo puede seleccionar varios grupos y resolverlos, reabrirlos o silenciarlos de una vez (hasta 100 por operación). Cada grupo se procesa por separado: si uno falla, los demás siguen.
Avisos que recibe tu servidor
Tu aplicación puede recibir seis eventos de errores. El contenido de cada uno está en Contenido de los avisos:
ERROR_REPORTED: tu aplicación ha enviado un error nuevo. No se repite cuando un error ya conocido vuelve a ocurrir y solo sube su contador.ERROR_RESOLVED: tu equipo ha resuelto un grupo.ERROR_REOPENED: tu equipo ha reabierto un grupo resuelto.ERROR_SILENCED: un grupo se ha silenciado o se ha quitado el silencio.ERROR_LINKED_TO_TICKET: se ha creado y enlazado un ticket de soporte.ERROR_LINKED_TO_ISSUE: se ha creado y enlazado un elemento de trabajo.
Todos se firman y se reintentan igual que el resto de avisos: Firma HMAC y Entregas y reintentos. Solo llegan los eventos a los que suscribas la aplicación en su sección Avisos a tu servidor.
Buenas prácticas para tu aplicación
Lo que envíes decide lo útil que le resultará a tu equipo:
- Agrupa de forma estable: el grupo se calcula con el mensaje, el módulo y la ruta normalizados. Si el mensaje lleva identificadores que cambian, quítalos antes de enviarlo (
Order ${id} not found→Order :id not found) para que las repeticiones se sumen. - Usa
severitycon criterio:criticalpone el estado en rojo y avisa a todo el equipo. Resérvalo para incidentes que afectan al servicio. - Aprovecha
context: lo que mandes ahí aparece en el detalle del error, después de quitarle correos, tokens y credenciales. Es la mejor pista para diagnosticar. - Escucha
ERROR_RESOLVED: si tu aplicación cierra sus alertas internas cuando tu equipo resuelve el error, evitas alertas que nadie atiende.
Siguiente paso
Cómo enviar los errores lo explican Errores de tu aplicación (desde tu servidor) y Errores del navegador (desde el SDK o el widget).