Rerun Failed Jobs in HyperExecute From the Job Page

Rerun a Failed Job From the Job Page

The rerun lives on the job itself, so you start where you read the failure. The steps below follow the Rerun Failed Jobs documentation.

• Open the job from the Jobs page.
• Click Re-Run in the top bar.
• Under Scope of Rerun, choose the failed scenarios or all scenarios. The dialog shows how many scenarios each option will run, so you see the size of the rerun before you start it.
• Pick the same commit or the latest commit, change concurrency if you want to, and click Rerun.

The new job opens, and you follow it like any other job. The dialog can also carry a notice before you start, such as one of the two rerun types being unavailable, or a named tunnel that has to be running first.

Rerun Failed Scenarios or All Scenarios

A scenario is one discovered unit of work, such as one test file in an auto-split job. The rerun type decides which of the original job's scenarios run again.

A failed-scenarios rerun is the retesting step: confirm the fix on what broke. Run an all-scenarios rerun, or your normal pipeline, when you also need the regression pass over everything else.

Same Commit or Latest Commit

Either rerun type can run on the commit the original job ran or on the newest commit of that branch. The YAML stays the original job's in both cases, so only the code differs.

How Failed Scenarios Are Picked

A scenario goes into a failed-scenarios rerun when it did not finish successfully. The edge cases follow the job's own retry and fail-fast settings.

• Retries - a scenario that failed and then passed on a retry counts as passed and is not rerun. If the retry never finished, the scenario is rerun.
• Fail fast - when fail fast stops a job, the scenario that tripped the limit counts as a failure, and the scenarios that never started are included too, because they have no result yet.
• Dependent scenarios - scenarios that run as a dependent group rerun together. One member of the group cannot be rerun on its own.
• Several test cases in one scenario - all of them rerun, including the ones that passed inside a failed scenario.

retryOnFailure with maxRetries (1 to 5 attempts) absorbs a transient failure inside the job. A rerun comes after the job, once you have a fix or a question to ask of the same code. Both are part of HyperExecute's AI-native test orchestration, which decides how a suite is split, where it runs and what runs again.

Each Rerun Is a Full Job

A rerun is a new HyperExecute job, not a retry of individual tests inside the old one. It checks the code out again, runs with the original YAML, and gets its own job number, logs and results.

• Label - the original job's labels carry over, with Rerun-#<original job number> added as the first label, so reruns stand out in the Jobs list.
• Traceable chain - you can rerun a rerun, and each label points at its own parent.
• Original untouched - the first job and its results stay as they were, so you can put the failing run and the rerun side by side.
• Same project - the rerun belongs to the project the original job ran in. Your policies are applied fresh to the new job.
• Billing - a rerun uses concurrency and minutes like any job of its size. Re-verifying 20 failures is billed as a 20-scenario job.

Because the rerun has its own logs, a same-commit rerun that fails the same way gives you a second, clean set of evidence to find the root cause of a failed test. A same-commit rerun that passes points at the environment or test data rather than the code.

A 10-Scenario Job With 2 Planted Failures

To see what a rerun would pick, I built a 10-file pytest suite against the Selenium Playground, with Selenium 4.52.0 on the TestMu AI grid and two failures planted on purpose. This is its YAML: auto-split, one scenario per test file, five Linux machines.

# hyperexecute.yaml, part 1 of 2: machines and project
version: 0.1
runson: linux
autosplit: true
concurrency: 5
retryOnFailure: false
scenarioCommandStatusOnly: true

globalTimeout: 30
testSuiteTimeout: 30
testSuiteStep: 30

project:
  name: rerun-failed-jobs-demo
jobLabel: [rerun-demo]

# hyperexecute.yaml, part 2 of 2: runtime, discovery and runner
runtime:
  language: python
  version: "3.10"

pre:
  - pip install -r requirements.txt

testDiscovery:
  type: raw
  mode: local
  command: git ls-files tests/test_*.py

testRunnerCommand: pytest -v $test

The two parts rejoin, without their comment lines and with one blank line between them, into the committed file. The job below ran from a clean clone of the suite, with one line changed in a copy of this file: the project name, rerun-demo-validation.

The first planted failure types 12 and 30 into the Simple Form Demo and asserts the sum is 43. The second filters the table demo for Halima and expects the status in progress, while the page shows completed.

Both tests take a driver fixture and an open_page helper from the suite's conftest.py. The fixture opens Chrome on the TestMu AI grid with credentials read from the LT_USERNAME and LT_ACCESS_KEY environment variables, and marks each session passed or failed.

from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.ui import WebDriverWait

from conftest import open_page


def test_simple_form_adds_two_values(driver):
    open_page(driver, "simple-form-demo")
    wait = WebDriverWait(driver, 15)
    wait.until(EC.visibility_of_element_located((By.ID, "sum1"))).send_keys("12")
    driver.find_element(By.ID, "sum2").send_keys("30")
    driver.find_element(By.XPATH, "//button[normalize-space()='Get Sum']").click()
    wait.until(lambda d: d.find_element(By.ID, "addmessage").text.strip() != "")
    assert driver.find_element(By.ID, "addmessage").text.strip() == "43"

I ran the suite with HyperExecute CLI v0.2.364 on 5 November 2026, and each machine installed Selenium 4.52.0 and pytest 9.2.0 on Python 3.10.16. These are the test-stage lines the CLI printed, where the number in brackets is the machine.

    x [1]  tests/test_table_filter.py (15s)
    x [2]  tests/test_simple_form_sum.py (14s)
    ✔ [4]  tests/test_smoke_alerts_page.py (13s)
    ✔ [5]  tests/test_smoke_checkbox_page.py (13s)
    ✔ [2]  tests/test_smoke_dynamic_data_page.py (3s)
    ✔ [1]  tests/test_simple_form_message.py (6s)
    ✔ [4]  tests/test_range_slider.py (4s)
    ✔ [3]  tests/test_smoke_ajax_form_page.py (16s)
    ✔ [5]  tests/test_select_dropdown.py (3s)
    ✔ [3]  tests/test_radio_button.py (3s)

The job summary followed, and the CLI ended with Error: Failed tasks found.

 FAILED 
    Test Execution Time:                  12s
    Job Duration Time:                    1m15s
    Total Tasks:                          5
    Cumulative Time Consumed:             5m51s
    Total Stages:                         20
    Pass discovery stage percentage:      100.00%
    Failed discovery stage percentage:    0.00%
    Pass pre stage percentage:            100.00%
    Failed pre stage percentage:          0.00%
    Pass test stage percentage:           80.00%
    Failed test stage percentage:         20.00%
    Pass post stage percentage:           0.00%
    Failed post stage percentage:         0.00%
    Failed Tasks:                         2

• Original job - 10 scenarios on 5 machines, 8 passed, 2 failed, Job Duration Time 1m15s and Cumulative Time Consumed 5m51s.
• Failure messages - the pytest logs, downloaded with --download-logs, show assert '42' == '43' for the sum and a Halima row that reads 2 Testing Halima Werknesh completed.
• Failed Tasks: 2 - a task is one machine, not one scenario. Here the failing files landed on machines [1] and [2]; in an earlier run of the same suite both landed on one machine and the line read Failed Tasks: 1.
• Failed-scenarios rerun - by the selection rules above, it runs 2 scenarios, test_simple_form_sum.py and test_table_filter.py, which took 14 s and 15 s in this job.
• All-scenarios rerun - runs all 10 files again.

Job Duration Time, 1m15s here, is the wall-clock figure to compare a rerun against. For how full-suite run times compare across testing clouds, see which is the fastest AI testing cloud for reducing test execution time.

This job also shows the first prerequisite in action. It ran from a local folder with no Git remote, so a rerun would have nowhere to check the code out from. The suite has to be pushed to GitHub, Azure Repos or Bitbucket, with a token HyperExecute can use, before its jobs can be rerun.

Current Limits of Rerun Failed Jobs

Rerun works today on Git-based jobs that use YAML version 0.1, and support for more job types is planned. Where a job cannot be rerun, the Re-Run button is not shown at all.

• Dashboard only - a rerun cannot be started from the CLI or an API yet.
• Git and a token - the suite must be on GitHub, Azure Repos or Bitbucket. HyperExecute uses the project's access token first and falls back to a secret named git_token saved at user, project or organization level.
• Local CLI jobs - a job started from your machine can be rerun only if Git details were recorded and the working tree was clean. Commit or stash before you run it.
• Mobile jobs - jobs that ran Appium tests are not supported yet.
• Local global steps - a job whose globalPre or globalPost step ran with mode: local cannot be rerun, because that step runs on the machine that started the job.
• Job state - no rerun while the job is still running, when nothing failed, when it is older than the retention window, or when its project has been deleted.

On-premises HyperExecute setups got rerun support in HyperExecute release 3.5.7, which also fixed the Rerun button being wrongly disabled with a concurrency error when you switched between Same Commit and Latest Commit.

Get Started

There is nothing to change in your YAML or pipeline. Make sure your jobs meet the prerequisites, then rerun from the job page.

• Link the repository to a HyperExecute project with an access token, as described in the HyperExecute projects documentation, or save a git_token secret.
• Keep version: 0.1 in the YAML and run the job from your pipeline or the CLI as usual.
• When a job fails, open it from the Jobs page, click Re-Run, and pick the failed scenarios on the same commit to reproduce, or on the latest commit to verify the fix.

The Rerun Failed Jobs documentation lists every prerequisite and the reasons a job cannot be rerun. For how auto-split, retries and fail fast fit together across a suite, see the guide to test orchestration.

Austin Siewert

Co-Founder, Steadfast Systems

Discovered @TestMu AI yesterday. Best browser testing tool I've found for my use case. Great pricing model for the limited testing I do 👏

3M+ Devs and QAs rely on TestMu AI

Deliver immersive digital experiences with Next-Generation Mobile Apps and Cross Browser Testing Cloud

Sign up with googleSign up with Email

Fix the 20 that failed, then rerun the 20.