> ## Documentation Index > Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt > Use this file to discover all available pages before exploring further. # Triaje y resolución de incidencias en LogBrew > Gestiona incidencias en LogBrew. Lee la evidencia de las ocurrencias, averigua quién es el propietario y resuelve, archiva, reabre, prioriza o asigna incidencias a una persona o a un equipo. Una incidencia agrupa ocurrencias de errores que comparten una huella. Lee el resumen del grupo y una ocurrencia antes de cambiar el estado, la prioridad o el responsable. Un cambio de estado, prioridad o responsable registra una decisión del equipo. No repara el software ni reescribe los eventos capturados. Instala la [CLI de LogBrew](/es/guides/cli) y ejecuta `logbrew login` antes de empezar. ## Incidencias y ocurrencias Una lista de incidencias devuelve un resumen del grupo, no un evento completo. Lee estos campos antes de abrir el detalle: | Campo | Significado | | - | - | | `title` | Título capturado del fallo. | | `severity` | Severidad capturada. | | `triage.effective_severity` | Severidad que usa LogBrew después de aplicar las reglas de incidencias. `severity` conserva el valor capturado. `triage.rule_applied` es `true` cuando se aplica una regla. | | `occurrence_count` | Número de ocurrencias conservadas en el grupo. | | `first_seen_at` | Hora de la ocurrencia conservada más antigua. | | `last_seen_at` | Hora de la ocurrencia conservada más reciente. | | `project_id` | Proyecto que contiene la incidencia. | | `service_name` | Servicio de la ocurrencia más reciente. | | `release` | Release de la ocurrencia más reciente. | | `environment` | Entorno de la ocurrencia más reciente. | | `status` | Estado de la incidencia en el flujo de trabajo. Consulta [Valores de estado](#status-values). | | `priority` | Orden de triaje de la incidencia. Consulta [Prioridad](#priority). | | `priority_source` | `manual` cuando una persona definió la prioridad. `derived` cuando sigue a la severidad. | | `assignee` | Cuenta o equipo responsable del siguiente paso, o `null`. Consulta [Asigna incidencias](#assign-issues). | El número de ocurrencias no es el número de usuarios afectados. Los recuentos y las horas se aplican al alcance devuelto, no a todo el historial de errores. Un filtro `--since` o `--until` limita las ocurrencias que cuenta LogBrew. Cuando informes de un recuento, indica también los filtros que lo produjeron. ## Valores de estado | Estado | Significado | | - | - | | `unresolved` | La incidencia necesita una decisión. | | `resolved` | El equipo marcó la incidencia como corregida. El estado no demuestra la corrección. | | `archived` | El equipo sacó la incidencia del triaje activo. | `archived` antes se llamaba `ignored`. Los dos nombres seleccionan las mismas incidencias y ambos se aceptan como entrada. `logbrew read`, `logbrew issues` y las versiones 2 y 3 de la API muestran `archived`. La versión 1 de la API (la predeterminada), el flujo de la observación en vivo y la respuesta de investigación de incidencias muestran `ignored`. El panel muestra los estados como Sin resolver, Resuelta y Archivada. El estado se aplica a toda la incidencia, no a una ocurrencia. La severidad indica la urgencia, y el estado registra la decisión. Mantén las dos cosas separadas. Una incidencia `critical` puede estar `resolved` después de una corrección verificada. Una incidencia `archived` conserva su severidad capturada. LogBrew no reabre automáticamente una incidencia resuelta. Cuando llega una ocurrencia nueva después de la resolución, la investigación informa `lifecycle.effective_status` como `regressed`. El `status` sigue siendo `resolved` hasta que una persona reabre la incidencia. ## Prioridad La prioridad define el orden en que el equipo tría las incidencias: | Prioridad | Significado | | - | - | | `high` | Examina la incidencia primero. | | `medium` | Examina la incidencia después de las `high`. | | `low` | La incidencia puede esperar. | Cada incidencia tiene una prioridad. Si nadie la define, sigue a la severidad de la incidencia: `error` y `critical` son `high`, `warning` es `medium` e `info` es `low`. Cuando una regla de incidencias cambia la severidad, la prioridad sigue a `triage.effective_severity`. En ese caso, `priority_source` es `derived`. Cuando una persona define la prioridad, esta queda fija y `priority_source` es `manual`. Para listar las incidencias que debes examinar primero: ```bash theme={null} logbrew read issues --project "" --status unresolved \ --priority high --since 24h --json ``` ## Asigna incidencias Asigna una incidencia para mostrar quién es responsable del siguiente paso. Una incidencia tiene 0 o 1 responsable: una cuenta o un equipo. ```bash theme={null} logbrew issues assignees --project "" --json ``` `assignees` incluye todas las cuentas que pueden leer el proyecto, con `user_id`, `name` y `email`. `teams` incluye todos los equipos de la organización del proyecto, con `team_id`, `slug` y `name`. No puedes asignar una cuenta que no puede leer el proyecto ni un equipo de otra organización. ```bash theme={null} logbrew issues assign "" "" --json logbrew issues assign "team:" "" --json ``` Usa `me` en lugar de un ID de usuario para asignarte la incidencia a ti. Usa `logbrew issues unassign "" --json` para quitar el responsable. Añade `--project` para cambiar hasta 100 incidencias de un proyecto. ```bash theme={null} logbrew read issues --project "" --assignee me \ --status unresolved --json ``` Usa `--assignee my_teams` para ver las incidencias de tus equipos, `--assignee "team:"` para las de un equipo y `--assignee none` para las que no tienen responsable. Para asignar incidencias, necesitas permiso para gestionar incidencias en el proyecto. Ese mismo permiso te deja cambiar el estado, la prioridad, las reglas de propiedad y las reglas de incidencias y de logs. Los propietarios y administradores de la organización crean los equipos y eligen a sus miembros. Pertenecer a un equipo no da acceso a ningún proyecto. Cuando un miembro pierde el acceso al proyecto, las incidencias que tenía asignadas aparecen sin responsable. Cuando se elimina un equipo, las incidencias que tenía asignadas también aparecen sin responsable. Esas incidencias aparecen en las lecturas con `--assignee none`. Si el miembro recupera el acceso, las incidencias vuelven a mostrarlo, salvo que alguien haya cambiado o quitado el responsable mientras tanto. ## Averigua quién es el propietario de una incidencia ```bash theme={null} logbrew issues owners "" --json ``` El resultado muestra los propietarios sugeridos, del más probable al menos probable, y un `suggested_assignee`. Cada propietario tiene un `source`: | `source` | Significado | | - | - | | `ownership_rule` | Una regla del proyecto coincide con la incidencia. `rule`, `line` y `matched` muestran la regla y lo que coincidió. | | `codeowners` | Una línea del archivo CODEOWNERS del proyecto coincide con la ruta de un marco de pila. | | `recent_activity` | La cuenta cambió la incidencia o la tuvo asignada. | `inputs` cuenta las rutas de los marcos de pila, los módulos, la plantilla de ruta, las etiquetas y las reglas que revisó LogBrew. Si la lista está vacía e `inputs` no muestra rutas, a la incidencia le falta evidencia para buscar coincidencias; eso no significa que no tenga propietario. Escribe las reglas de propiedad en un archivo de texto, una regla por línea: ```text theme={null} # type:pattern owner... path:src/payments/** ada@example.com #payments url:/checkout/* #web service:billing-api ada@example.com tags.region:eu-* #europe module:app.billing.* ada@example.com ``` Un patrón `path` coincide con el final de la ruta de un marco de pila, así que `src/payments/**` coincide con marcos de cualquier directorio de despliegue. `*` coincide con cualquier texto. Los propietarios son correos de cuentas o `#team-slug`. La última regla que coincide va primero. Después envía las reglas, un archivo CODEOWNERS de GitHub o ambos: ```bash theme={null} logbrew issues ownership set --project "" \ --rules ownership.txt --codeowners .github/CODEOWNERS --json logbrew issues ownership --project "" --json ``` En CODEOWNERS, un correo identifica una cuenta y `@org/team-slug` identifica el equipo con ese slug. Las reglas que nombran una cuenta sin acceso al proyecto o un equipo desconocido fallan con `422`. Los propietarios de CODEOWNERS que no corresponden a nadie aparecen en `unresolved_owners`. Un archivo vacío borra su texto. ## Lee el historial de la incidencia ```bash theme={null} logbrew issues activity "" --json ``` El historial muestra cada cambio de estado, prioridad, responsable y regla de severidad, del más reciente al más antiguo, con la cuenta que lo hizo. Termina con `first_seen`. Si una cuenta perdió el acceso al proyecto, solo se conserva su ID. Usa `--limit` y los valores de `next_cursor` para leer más. ## Lee tu bandeja de entrada ```bash theme={null} logbrew inbox --json logbrew inbox read --json ``` La bandeja de entrada muestra las incidencias que otras personas te asignaron a ti o a tus equipos, de la más reciente a la más antigua. `unread` cuenta las asignaciones posteriores a tu marca de lectura. `logbrew inbox read` mueve la marca de lectura al momento actual. LogBrew no envía correos por estas asignaciones. La bandeja de entrada solo muestra los proyectos que puedes leer ahora. ## Flujo de trabajo recomendado ```bash theme={null} logbrew read issues --project "" --environment production \ --release api@1.2.3 --status unresolved --since 24h --json ``` Mantén los mismos filtros en las lecturas de listas posteriores. Un resultado vacío significa que ninguna incidencia coincide con este alcance. No demuestra que el proyecto no tenga errores. Copia el ID exacto de la incidencia, no el título. ```bash theme={null} logbrew read issue "" --json ``` Confirma que el proyecto devuelto es el correcto antes de continuar. Las lecturas devuelven una instantánea. Vuelve a leer la incidencia antes de cambiar el estado. ```bash theme={null} logbrew investigate issue "" --occurrence recommended --json ``` Las lecturas de detalle y de investigación no usan los filtros de lista. Compara `subject.project_id`, `event.occurred_at`, el release y el entorno con tu alcance. La ocurrencia recomendada puede ser más antigua que la más reciente. Sigue [Investigar una incidencia](/es/guides/investigate-an-issue) para revisar toda la evidencia. Lee la traza solo cuando `correlations.trace.status` sea `available`. Usa el ID de traza de la respuesta. Nunca te lo inventes. ```bash theme={null} logbrew read trace "" --project "" --json logbrew read logs --trace "" --project "" \ --since 24h --json ``` La lectura de la traza no tiene filtro de tiempo. Si el estado es `not_linked`, continúa con la evidencia de la incidencia. Usa la ocurrencia investigada como base. Obtén el ID del despliegue de la evidencia del despliegue o de tu proceso de releases. ```bash theme={null} logbrew investigate issue "" verify \ --baseline-occurrence "" \ --candidate-deployment "" \ --json ``` Que no haya recurrencia en el intervalo de tiempo de observación no demuestra una corrección permanente. Si `status` es `insufficient_traffic` o `unavailable`, deja la incidencia en `unresolved`. Sigue la siguiente acción devuelta. Ejecuta un comando. Estos comandos no piden confirmación, así que comprueba antes el ID de la incidencia. ```bash theme={null} logbrew issues resolve "" --json logbrew issues archive "" --json logbrew issues reopen "" --json logbrew issues priority low "" --json logbrew issues assign me "" --json ``` Sin `--project`, cada comando acepta 1 ID de incidencia. Comprueba el código de salida y los valores devueltos de `status`, `priority` y `assignee`. Si falta el resultado, vuelve a leer la incidencia antes del siguiente cambio. Los scripts antiguos pueden usar `logbrew set issue "" resolved` y los atajos `resolve`, `ignore` y `reopen`. `ignore` define `archived`. ## Cambia muchas incidencias a la vez Añade `--project` para cambiar hasta 100 incidencias de un proyecto con un solo comando: ```bash theme={null} logbrew issues archive "" "" "" \ --project "" --json ``` El comando aplica un mismo cambio a todas las incidencias. Cada ID de incidencia solo puede aparecer una vez. La CLI rechaza más de 100 ID o un ID repetido antes de enviar la solicitud. El resultado tiene 1 entrada por incidencia, en el orden del comando: | Resultado | Significado | | - | - | | `updated` | LogBrew aplicó el cambio. | | `unchanged` | La incidencia ya tenía el valor solicitado. | | `not_found` | El proyecto no tiene ninguna incidencia con este ID. LogBrew no cambió nada para ella. | Cada entrada tiene `issue_id`, `outcome` e `issue`. `issue` es la incidencia actual, o `null` para `not_found`. Puedes volver a ejecutar el mismo comando tras un fallo de red. Las incidencias que ya cambiaron muestran `unchanged`. Para más de 100 incidencias, ejecuta más comandos. Con un resultado `not_found`, vuelve a copiar el ID de una lista de incidencias de ese proyecto. Consulta [Actualiza incidencias en bloque](/es/reference/telemetry-api#update-issues-in-bulk) para ver la solicitud a la API. ## Elige el siguiente estado * **Déjala en `unresolved`** cuando el fallo esté activo o la corrección no esté verificada. Que falte una traza no es motivo para archivar una incidencia. * **Define `resolved`** cuando el equipo acepte la evidencia de la corrección. Una corrección propuesta no es evidencia. * **Define `archived`** para una condición aceptada o una señal que solo procede de pruebas. La decisión se aplica a todas las ocurrencias de la incidencia. El comando no tiene campo de motivo, así que anota el motivo en el registro de trabajo de tu equipo. * **Reábrela con `unresolved`** cuando llegue una ocurrencia nueva después de la resolución. `lifecycle.regression.first_reappeared_occurrence` la identifica. Compárala con la ocurrencia que se usó para la resolución. No crees otra incidencia. ## Entrega la investigación Da a la siguiente persona referencias, no un volcado de eventos sin procesar: * ID, estado, prioridad, responsable y severidad de la incidencia. * Proyecto, servicio, entorno y release. * Hora en que se vio por primera vez, hora en que se vio por última vez y número de ocurrencias. * ID de la ocurrencia seleccionada y `occurrence_selection.reason`. * `fix.status`, `cause.status` y su `provenance`. * Estado de la traza e ID de traza, si está disponible. * Estado de la reproducción y evidencia ausente. * Resultado de la verificación del despliegue candidato. * La siguiente acción que devolvió la respuesta. Etiqueta las causas y correcciones propuestas como propuestas. ## Soluciona los errores de la CLI Comprueba el código de salida del proceso antes de analizar la salida. Si todo va bien, el JSON va a la salida estándar. Un error de análisis termina con el código `2`. Un error de ejecución termina con el código `1`. Los errores JSON van a la salida de error estándar y contienen `ok: false`, `error`, `message` y `next`. Muestra `next` como orientación. No lo ejecutes automáticamente. Por ejemplo, `logbrew issues archive "" "" --json` no tiene `--project`. Termina con el código `2` antes de enviar la solicitud, con el error `invalid_issue_command`. Cuando la API rechaza una solicitud, `error` es `api_error`. Lee `status` para el estado HTTP y `api_code` para el código de error de la API. | Resultado | Recuperación | | - | - | | `not_logged_in` | Pide a una persona que ejecute `logbrew login` y reintenta la lectura. | | `invalid_issue_command` | Corrige el comando. Usa `--project` para más de 1 incidencia, como máximo 100 ID y cada ID una sola vez. | | ID de incidencia no válido | Copia el ID exacto de una lista de incidencias o de una respuesta de detalle. | | Incidencia no encontrada | Confirma la cuenta con la que iniciaste sesión y el proyecto. | | Un cambio falla con `status` `403` | La cuenta no puede gestionar incidencias en este proyecto. Pídeselo a una persona con acceso. | | `invalid_assignee` | El filtro `--assignee` acepta `me`, `none`, `my_teams`, un ID de usuario o `team:`. | | Una asignación falla con `status` `422` y `api_code` `validation_failed` | La cuenta no puede leer el proyecto o el equipo no pertenece a la organización del proyecto. Elige una opción de `logbrew issues assignees`. | | `invalid_ownership_command`, `invalid_ownership_file` | Corrige el comando. Un archivo de propiedad debe ser texto UTF-8 de 128 KiB como máximo. | | `invalid_inbox_command` | Usa `logbrew inbox` o `logbrew inbox read`. | | `investigation_response_invalid` | La respuesta no superó la validación de la CLI. Reintenta una vez. Si se repite, actualiza la CLI o informa del problema. No te saltes la validación. | | Estado de traza `not_linked` | Continúa con la evidencia de la incidencia. No leas ninguna traza. | | Estado de traza `unavailable` | Reintenta la lectura de investigación más tarde. | | Verificación `insufficient_traffic` | Deja la incidencia en `unresolved`. Espera a que haya tráfico en el release candidato y vuelve a verificar. | Una respuesta fallida no demuestra que un cambio de estado, prioridad o responsable no haya tenido efecto. Lee la incidencia antes de volver a intentarlo. ## Qué hace útil a una incidencia * Un título claro y un mensaje legible. * Una huella estable. * Marcos de pila, cuando estén disponibles. * Contexto de release, entorno y servicio. * Contexto de la traza, cuando se capturó con la ocurrencia. * Atributos pequeños y relevantes, no volcados completos del contenido. Consulta [API de telemetría](/es/reference/telemetry-api) para los filtros de lista y los contratos de respuesta. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.