---
title: Mi ejecución ha fallado
question: ¿Qué hago cuando una ejecución termina en fallo?
description: Leer la categoría de error, entender qué significa y saber si conviene relanzar.
section: solve
order: 2
---
Abra la ejecución en **Ejecuciones**: la categoría de error aparece arriba, y es la que le dice qué hacer. Un fallo no es necesariamente una avería: lo más habitual es que el pipeline se haya negado a entregar un trabajo que consideraba insuficiente.

## ¿Qué significan las categorías de error?

**Verificación insuficiente**: el código producido no alcanzó la puntuación mínima, ni siquiera tras los intentos de corrección. La merge request existe, en borrador, con las objeciones como comentarios. Léalas: a menudo la incidencia era ambigua, a veces falta una convención interna en sus contextos.

**Pregunta sin respuesta**: el agente lector necesitaba una precisión y nadie contestó. Véase [Diavi me hace una pregunta](/help/es/clarification-demandee/).

**Intervención humana necesaria**: el pipeline encontró algo que no sabe resolver solo. La merge request contiene lo que se ha podido hacer, y el comentario dice dónde se atasca.

**Respuesta demasiado larga**: el modelo alcanzó su tope de salida en plena tarea. Ocurre en incidencias que tocan muchos archivos de golpe. Divida la incidencia en dos y vuelva a lanzar.

**Infraestructura**: un incidente de nuestro lado. Esa ejecución **no se descuenta** de su cuota. Vuelva a lanzar; si se repite, escríbanos.

## ¿Conviene relanzar?

Relanzar sin cambios solo sirve si el fallo fue un error de infraestructura. En todos los demás casos, cambie algo antes: precisar la incidencia, dividirla, o añadir la convención que falta a sus contextos. Sin cambios, la segunda ejecución chocará con el mismo muro que la primera, y contará en su cuota.

## ¿Dónde veo el detalle?

La pestaña **Registros** muestra el desarrollo completo, etapa por etapa. Un glosario explica allí los términos que se repiten.
