// SYS.ONLINE — 2501.AI COMMAND INTERFACE
[STATUS: ACTIVE]
2501/Agent specialties/CI Manager/Failed CI run: flaky or real?

SOLUTION //

CI Manager

Failed CI run: flaky or real?

Rerunning a failed pipeline until it passes wastes build time and hides real breaks. How 2501 retries transient CI failures once and sends real ones to their owner.

A failed CI run is classified by 2501 as transient or real: a transient failure is retried once, and a real one goes with the evidence to the author, the platform team or the service owner

ServiceNow or another ITSM

Your rules, confirmation and blacklists

Investigate only, with a person, or on its own

On-prem, cloud or hybrid

SOLUTION_BRIEFING

// HOW 2501 HANDLES IT

Rerunning a failed pipeline until it turns green is the quick fix, but it treats a broken test like a network hiccup and burns build time. 2501 works out why the run failed, retries it once when the cause was transient, and sends a real failure to whoever owns the fix.

A run can fail because a download timed out or a build machine dropped out, or because of a broken test, an expired credential or a deployment that failed its checks. Each has a different owner.

What 2501 does

The CI specialty reads the failed run before it touches anything and classifies the failure. A transient one gets a single retry, and the agent waits for the result before closing the ticket; if the same failure comes back, it is real. A real failure goes with the evidence to its owner: the author of the change for a failing test or build, the platform team for credentials and build machines, the service owner for a deployment. It reports what failed, why and what it did, across GitHub Actions, GitLab CI, Jenkins, CircleCI and Azure DevOps.

How 2501 handles a failed CI run: signal, classify the failure as transient or real, retry a transient failure once within your rules, send a real failure with the evidence to whoever owns the fix

You stay in control

  • You choose the level: investigate only, act after a person confirms, or act on its own within your rules. The level is set per specialty, not per ticket.
  • One retry, never a loop: a failure is retried once at most, and one that fails the same way every time, such as a broken test, is not retried at all.
  • Pipelines and credentials stay yours: it never edits pipeline definitions or stored credentials, and never restarts shared production build machines on its own.
  • Your rules apply: which pipelines it may retry unattended, and which failures go straight to a person.

Frequently asked

Why not rerun a failed deployment straight away? A deployment that failed partway can leave the environment half updated, and running it again on top can make things worse. The environment's state is confirmed first.

Can it classify failures without retrying anything? Yes. In investigate-only mode it reports why the run failed and who owns the fix, and retries nothing.

Related

> READY_TO_DEPLOY

SEE IT ON YOUR OWN INFRASTRUCTURE

Book a technical demo and walk through your own environment with the 2501 team.

REQUEST DEMO

CONTACT SALES