Observabilidad

Observabilidad

Los roles owner y admin tienen acceso a un panel de observabilidad básico que muestra errores recientes, métricas de uso y los identificadores que necesitás para reportar problemas al equipo de soporte de Asientra.

Video próximamente · 3min

Nota

La observabilidad está diseñada para dos casos de uso: diagnóstico proactivo (¿está todo funcionando bien?) y reporte de incidentes (algo falló, ¿cómo lo reporto con la información correcta?). No expone data financiera — solo metadata de las operaciones.

Panel de estado del despacho

Andá a Admin → Observabilidad. El panel muestra:

• Estado general: indicador verde/amarillo/rojo del sistema. Verde = todo funcional. Amarillo = hay errores no críticos. Rojo = hay errores que pueden estar afectando operaciones.
• Errores recientes: los últimos 20 errores detectados en el despacho, con timestamp, tipo de error y el request_id de la operación que falló.
• Jobs fallidos: jobs en background (sync de TRIBU-CR, envíos a Hacienda, generación de PDFs) que fallaron en las últimas 24 horas.
• Métricas básicas: tiempo de respuesta promedio de las últimas 4 horas, cantidad de operaciones por hora.

Panel de observabilidad con estado general, errores recientes y jobs fallidos

1

Identificá errores activos

En la sección Errores recientes, cada entrada muestra:

• Timestamp: cuándo ocurrió.
• Tipo: qué categoría de error fue (autenticación, facturación, sync TRIBU-CR, generación de estado financiero, etc.).
• Usuario: qué usuario estaba operando cuando ocurrió (si aplica).
• Request ID: el identificador único de esa operación en el sistema.
• Mensaje resumido: qué salió mal en lenguaje técnico.

Los errores de tipo critical aparecen en rojo con un ícono de alerta — son los que más probablemente están afectando la operación del despacho y deben atenderse primero.

Listado de errores recientes con columnas timestamp, tipo, usuario, request_id y mensaje

2

Encontrá el request_id de una operación que falló

Cuando algo falla en la app (un botón no responde como esperabas, una operación da error), la pantalla de error muestra un Request ID — un código alfanumérico único. Este ID es la clave para que el equipo de Asientra pueda encontrar exactamente qué pasó en los logs del servidor.

Cómo encontrar el request_id:

1. Reproducí el error.
2. En la pantalla de error, buscá el texto “Request ID: xxxxxxxx-xxxx-xxxx”.
3. Copiá el ID.
4. Usalo cuando contactás soporte.

Si el error desapareció de la pantalla antes de que pudieras copiarlo, podés buscarlo en Admin → Observabilidad → Errores recientes filtrando por la hora y el tipo de operación.

Pantalla de error de la app con request_id visible y botón copiar

3

Revisá jobs fallidos

En la sección Jobs fallidos, podés ver los procesos en background que no completaron. Los más relevantes para el despacho son:

• TribuCrSyncJob: el sync diario de TRIBU-CR falló. Causas en la guía de Sync diario.
• EnviarFacturaHaciendaJob: un comprobante no se pudo enviar a Hacienda. Revisá la factura en Facturas → Emitidas y el estado de la credencial del cliente.
• GenerarEstadoFinancieroJob: la generación de un estado financiero falló. Puede indicar cuentas sin mapeo NIIF o periodos sin cerrar.

Desde cada job fallido podés ver el mensaje de error específico y, si el problema ya fue resuelto, forzar un reintento.

Panel de jobs fallidos con tipo de job, cliente afectado, error y botón reintentar

4

Usá Sentry para errores técnicos avanzados

Asientra usa Sentry para capturar errores con stack traces. El equipo de soporte tiene acceso a Sentry — cuando reportás un bug con el request_id, el equipo puede correlacionar el error en Sentry y ver exactamente qué pasó a nivel de código.

Como usuario del despacho no tenés acceso directo a Sentry — es una herramienta interna del equipo de Asientra. Pero saber que existe te explica por qué el request_id es tan importante para acelerar el diagnóstico.

Cómo reportar un bug efectivamente

Cuando contactás al soporte de Asientra, incluí:

1. Request ID de la operación que falló (si lo tenés).
2. Qué estabas haciendo cuando ocurrió el error (paso a paso breve).
3. Qué esperabas que pasara vs qué pasó realmente.
4. Cliente y operación: qué cliente estaba activo y qué tipo de operación estabas haciendo (emitir factura, calcular D-104, etc.).

Con esta información el equipo puede diagnosticar el problema en minutos en lugar de horas.

Errores frecuentes

| Situación | Qué revisar | |---|---| | Estado general en amarillo/rojo | Revisar errores recientes y jobs fallidos; si son transitorios, esperar resolución automática | | Job fallido crítico (sync TRIBU-CR) | Ver la guía específica del job; si persiste, reportar con el request_id del último fallo | | Error repetido del mismo tipo | Puede indicar un problema de configuración (credenciales, plan de cuentas); contactar soporte con contexto |

Relacionado

• Soporte
• Costos de IA
• Usuarios y roles