Skip to main content

Run Command

The run command is the core of Rumour. It executes API requests or entire workflows.

Basic Usage

rumour run <PATH>
  • <PATH> - Path to a request file (.toml) or directory

Examples

Run a Single Request

rumour run requests/01_get.toml -y

Output:

GET https://httpbin.org/get
✓ SUCCESS: /home/bugsfounder/workspace/testing/run_example/requests/01_get.toml (1248ms)
✓ requests/01_get.toml → PASS (1 Pass, 0 Fail, 0 Skip)
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 1
│ Successful: 1
│ Failed: 0
│ Skipped: 0
│ Success Rate: 100.0% │
│ Total Time: 1248ms │
╰──────────────────────────────────────────────────────────────────────────╯

Actionable Recommendations:
→ Use -v -t to see detailed latency and response diagnostics.
→ Run with --json to export this report for your CI/CD pipeline.

Run a Directory (Workflow)

rumour run ./requests/ -y

Output:

⚠ Warning: Some variables are missing and will cause failures.
05_data needs variable user_id
GET https://httpbin.org/get
✓ SUCCESS: requests/01_get.toml (1248ms)
POST https://httpbin.org/post
✓ SUCCESS: requests/02_post.toml (875ms)
GET https://httpbin.org/bearer
✗ FAILED: requests/03_dependent.toml (387ms) - HTTP 401
↻ RETRYING: requests/03_dependent.toml (Attempt 1/2) [Wait 500ms]
GET https://httpbin.org/bearer
✗ FAILED: requests/03_dependent.toml (312ms) - HTTP 401
↻ RETRYING: requests/03_dependent.toml (Attempt 2/2) [Wait 1000ms]
GET https://httpbin.org/bearer
✗ FAILED: requests/03_dependent.toml (298ms) - HTTP 401
GET https://httpbin.org/status/404
✗ FAILED: requests/04_fail.toml (204ms) - HTTP Status: Expected status 200, got 404
✗ ./requests/ → FAIL (2 Pass, 3 Fail, 0 Skip)
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 5
│ Successful: 2
│ Failed: 3
│ Skipped: 0
│ Success Rate: 40.0% │
│ Total Time: 18931ms │
╰──────────────────────────────────────────────────────────────────────────╯

Failure Intelligence:
! Node: requests/03_dependent.toml
Reason: HTTP 401
! Node: requests/04_fail.toml
Reason: HTTP Status: Expected status 200, got 404
! Node: requests/05_data.toml
Reason: Variable resolution error: user_id - Missing/Invalid environment variable(s).

Actionable Recommendations:
→ Run with -H (Self-Healing) to attempt automatic recovery of failing nodes.
→ Use -v -t to see detailed latency and response diagnostics.

Understanding the Workflow Output

When executing a full directory of requests, Rumour provides deep visibility into the workflow lifecycle:

  1. Real-Time Execution Logs: Every request (01_get.toml, 02_post.toml, etc.) logs its method, URL, and latency as it executes.
  2. Automatic Retries: If a request fails, Rumour automatically retries it with intelligent exponential backoff (as seen with 03_dependent.toml retrying 3 times before giving up).
  3. Execution Report: A summary table at the end breaks down the run with your overall success rate and total execution time.
  4. Failure Intelligence: Failed nodes are listed with the exact reason — missing variables, assertion failures (e.g., expected 200, got 404), or authentication errors (HTTP 401).
  5. Actionable Recommendations: Rumour provides contextual hints on how to resolve issues, such as using -H (Self-Healing) for automatic recovery.

Command Options

OptionShortDescriptionDefault
--stop-on-fail-Stop execution on first failurefalse
--json-Output results in JSON formatfalse
--verbosevShow detailed execution summaryfalse
--tracetShow full failure detailsfalse
--healHShow self-healing recovery logsfalse
--resumerResume from previous executionfalse
--parallelpRun requests in parallelfalse
--hard-healXReconstruct missing resources (404)false
--auto-cleanupCDelete created resources after runfalse
--quietqSuppress all output except summaryfalse
--data-CSV/JSON file for data-driven testing-
--stress-Execute stress-test configuration defined in TOMLfalse
--junit-Save results to JUnit XML file-
--report-Open HTML execution dashboardfalse
--download-dirdCustom download directory/tmp/rumour/responses
--varVOverride variables (key=value)-
--header-Add or override headers-
--bodybOverride request body-
--extractEOverride extraction rules-
--dry-run-Don't send actual requestsfalse
--delay-Delay between requests (ms)0
--interactiveiInteractive healing on failurefalse
--env-fileeCustom environment file-
--vars-Output variables after executionfalse
--resources-Display resource mapfalse
--record-Record session to snapshot-
--replay-Replay from snapshot file-
--profile-Show performance profilingfalse
--yesyAuto-confirm overwritesfalse
--concurrencycMax concurrent requests20
--list-nodes-List all discovered nodesfalse
--stepSStep-by-step execution mode-

Detailed Options & Authentic Traces

Quiet Mode (-q, --quiet)

Suppress all output except the final summary.

rumour run requests/01_get.toml -q

Output:

PASS 01_get.toml

Verbose Mode (-v, --verbose)

Show a detailed execution summary table, listing every request executed.

rumour run requests/ -v -y

Output:

~/workspace/testing/run_example main* 5s ❯ rumour run requests/ -v -y
⚠ Warning: Some variables are missing and will cause failures.
⠁ Waiting for requests...
⠁ Executing: requests/
⚠ Warning: Some variables are missing and will cause failures.
05_data needs variable user_id
GET https://httpbin.org/get
URL: https://httpbin.org/get
✓ SUCCESS: /home/bugsfounder/workspace/testing/run_example/requests/01_get.toml (11731ms)
POST https://httpbin.org/post
URL: https://httpbin.org/post
✓ SUCCESS: /home/bugsfounder/workspace/testing/run_example/requests/02_post.toml (3509ms)
GET https://httpbin.org/bearer
URL: https://httpbin.org/bearer
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (4820ms) - HTTP 401
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (Attempt 1/2) [Wait 500ms]
GET https://httpbin.org/bearer
URL: https://httpbin.org/bearer
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (2067ms) - HTTP 401
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (Attempt 2/2) [Wait 1000ms]
GET https://httpbin.org/bearer
URL: https://httpbin.org/bearer
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (9030ms) - HTTP 401
GET https://httpbin.org/status/404
URL: https://httpbin.org/status/404
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (2471ms) - HTTP Status: Expected status 200, got 404
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (Attempt 1/2) [Wait 500ms]
GET https://httpbin.org/status/404
URL: https://httpbin.org/status/404
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (2403ms) - HTTP Status: Expected status 200, got 404
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (Attempt 2/2) [Wait 1000ms]
GET https://httpbin.org/status/404
URL: https://httpbin.org/status/404
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (2324ms) - HTTP Status: Expected status 200, got 404
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/05_data.toml (Attempt 1/2) [Wait 500ms]
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/05_data.toml (Attempt 2/2) [Wait 1000ms]
✗ requests/ → FAIL (2 Pass, 3 Fail, 0 Skip)
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 5
│ Successful: 2
│ Failed: 3
│ Skipped: 0
│ Success Rate: 40.0% │
│ Total Time: 42887ms │
╰──────────────────────────────────────────────────────────────────────────╯

✓ Successful Requests:
- /home/bugsfounder/workspace/testing/run_example/requests/01_get.toml [200] [11734ms]
- /home/bugsfounder/workspace/testing/run_example/requests/02_post.toml [200] [3511ms]

✗ Failed Requests:
- /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml: [401]
Reason: HTTP 401
- /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml: [404]
Reason: HTTP Status: Expected status 200, got 404
- /home/bugsfounder/workspace/testing/run_example/requests/05_data.toml:
Reason: Variable resolution error: {{base_url}}/anything?user={{user_id}} - Variable resolution error: user_id - Missing environment variable(s) or locked vault secret(s). Define them in a .env.toml file, runtime overrides, or unlock the vault.

Actionable Recommendations:
→ Run with -H (Self-Healing) to attempt automatic recovery of failing nodes.

Trace Mode (-t, --trace)

Show full failure details including raw error messages from assertions.

rumour run requests/04_fail.toml -t

Output:

~/workspace/testing/run_example main* 43s ❯ rumour run requests/04_fail.toml -t

GET https://httpbin.org/status/404
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (9227ms) - HTTP Status: Expected status 200, got 502
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (Attempt 1/2) [Wait 500ms]
GET https://httpbin.org/status/404
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (1057ms) - HTTP Status: Expected status 200, got 404
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (Attempt 2/2) [Wait 1000ms]
GET https://httpbin.org/status/404
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml (4290ms) - HTTP Status: Expected status 200, got 404
✗ requests/04_fail.toml → FAIL (0 Pass, 1 Fail, 0 Skip)
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 1
│ Successful: 0
│ Failed: 1
│ Skipped: 0
│ Success Rate: 0.0% │
│ Total Time: 16083ms │
╰──────────────────────────────────────────────────────────────────────────╯

Failure Intelligence:
! Node: /home/bugsfounder/workspace/testing/run_example/requests/04_fail.toml
Reason: HTTP Status: Expected status 200, got 404
Message:

Actionable Recommendations:
→ Run with -H (Self-Healing) to attempt automatic recovery of failing nodes.
→ Use -v -t to see detailed latency and response diagnostics.

JSON Output (--json)

Output raw JSON results suitable for CI/CD integration.

rumour run requests/01_get.toml --json

Output:

{"total_requests":1,"successful":[{"id":"/home/bugsfounder/workspace/testing/run_example/requests/01_get.toml","duration_ms":3032}],"failed":[],"skipped":[],"recovery_log":[],"results":{"/home/bugsfounder/workspace/testing/run_example/requests/01_get.toml":{"status":200,"body":"{\n \"args\": {}, \n \"headers\": {\n \"Accept\": \"*/*\", \n \"Host\": \"httpbin.org\", \n \"X-Amzn-Trace-Id\": \"Root=1-6a19a817-2580263b2a07ed1550f3536f\"\n }, \n \"origin\": \"152.59.155.246\", \n \"url\": \"https://httpbin.org/get\"\n}\n","body_path":null,"headers":{"date":"Fri, 29 May 2026 14:52:08 GMT","server":"gunicorn/19.9.0","access-control-allow-credentials":"true","content-length":"222","access-control-allow-origin":"*","content-type":"application/json"},"success":true,"failure_reason":null,"extracted_vars":{"X-Amzn-Trace-Id":"Root=1-6a19a817-2580263b2a07ed1550f3536f","01_get.X-Amzn-Trace-Id":"Root=1-6a19a817-2580263b2a07ed1550f3536f"},"assertion_results":[],"duration_ms":3030,"request_sent":{"method":"GET","url":"https://httpbin.org/get","headers":{},"body":null,"body_type":null,"params":null,"base_dir":"/home/bugsfounder/workspace/testing/run_example/requests"},"timings":{"dns_lookup_ms":0,"tcp_connect_ms":0,"tls_handshake_ms":0,"server_processing_ms":3030,"transfer_ms":0,"total_ms":3030},"is_replay":false}},"runtime_vars":{"/home/bugsfounder/workspace/testing/run_example/requests/01_get.toml.X-Amzn-Trace-Id":"Root=1-6a19a817-2580263b2a07ed1550f3536f","X-Amzn-Trace-Id":"Root=1-6a19a817-2580263b2a07ed1550f3536f","/home/bugsfounder/workspace/testing/run_example/requests/01_get.toml.01_get.X-Amzn-Trace-Id":"Root=1-6a19a817-2580263b2a07ed1550f3536f","01_get.X-Amzn-Trace-Id":"Root=1-6a19a817-2580263b2a07ed1550f3536f","base_url":"https://httpbin.org"},"session_vars":{},"execution_levels":[["/home/bugsfounder/workspace/testing/run_example/requests/01_get.toml"]],"total_time_ms":3032,"snapshots":null,"workflow_id":null}

Output Variables (--vars)

Print all extracted variables to stdout at the end of the run for debugging.

rumour run requests/02_post.toml --vars

Output:

PRE-FLIGHT DIAGNOSTIC REPORT

• /home/bugsfounder/workspace/testing/run_example/requests/02_post.toml
└─ base_url RESOLVED https://httpbin.org

POST https://httpbin.org/post
✓ SUCCESS: /home/bugsfounder/workspace/testing/run_example/requests/02_post.toml (9647ms)
✓ requests/02_post.toml → PASS (1 Pass, 0 Fail, 0 Skip)
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 1
│ Successful: 1
│ Failed: 0
│ Skipped: 0
│ Success Rate: 100.0% │
│ Total Time: 9649ms │
╰──────────────────────────────────────────────────────────────────────────╯

Actionable Recommendations:
→ Use -v -t to see detailed latency and response diagnostics.
→ Run with --json to export this report for your CI/CD pipeline.


RUNTIME VARIABLES:
/home/bugsfounder/workspace/testing/run_example/requests/02_post.toml.02_post.X-Amzn-Trace-Id = Root=1-6a19a868-4b84b536062552243dca5fdf
/home/bugsfounder/workspace/testing/run_example/requests/02_post.toml.X-Amzn-Trace-Id = Root=1-6a19a868-4b84b536062552243dca5fdf
02_post.X-Amzn-Trace-Id = Root=1-6a19a868-4b84b536062552243dca5fdf
X-Amzn-Trace-Id = Root=1-6a19a868-4b84b536062552243dca5fdf
base_url = https://httpbin.org

View Resources (--resources)

Display the detected REST resource topology based on URLs.

rumour run requests/ --resources

Output:

~/workspace/testing/run_example main* ❯ rumour run requests/ --resources
📦 RESOURCE TOPOLOGY

◆ anything
└─ 05_data.toml [DETECTED]

◆ bearer
└─ 03_dependent.toml [DETECTED]

◆ get
└─ 01_get.toml [DETECTED]

◆ post
└─ 02_post.toml [DETECTED]

◆ status
└─ 04_fail.toml [DETECTED]

List Nodes (--list-nodes)

Discover all request nodes in a directory without executing them.

rumour run requests/ --list-nodes

Output:

Discovered Nodes:
• 02_post (02_post.toml)
• 04_fail (04_fail.toml)
• 01_get (01_get.toml)
• 05_data (05_data.toml)
• 03_dependent (03_dependent.toml)

Note that nodes are shown in discovery order (filesystem order), not alphabetically. The node ID shown in parentheses is the short filename — this is what you pass to --step to target a specific node.

Stop on Fail (--stop-on-fail)

Immediately halt the workflow execution upon encountering the first failure.

rumour run requests/ --stop-on-fail -y
⚠ Warning: Some variables are missing and will cause failures.
⠁ Waiting for requests...
⠁ Executing: requests/
⚠ Warning: Some variables are missing and will cause failures.
05_data needs variable user_id
GET https://httpbin.org/get
✓ SUCCESS: /home/bugsfounder/workspace/testing/run_example/requests/01_get.toml (1428ms)
POST https://httpbin.org/post
✓ SUCCESS: /home/bugsfounder/workspace/testing/run_example/requests/02_post.toml (382ms)
GET https://httpbin.org/bearer
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (318ms) - HTTP 401
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (Attempt 1/2) [Wait 500ms]
GET https://httpbin.org/bearer
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (640ms) - HTTP 401
↻ RETRYING: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (Attempt 2/2) [Wait 1000ms]
GET https://httpbin.org/bearer
✗ FAILED: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml (573ms) - HTTP 401
✗ requests/ → FAIL (2 Pass, 1 Fail, 0 Skip)
╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 5
│ Successful: 2
│ Failed: 1
│ Skipped: 0
│ Success Rate: 40.0% │
│ Total Time: 4853ms │
╰──────────────────────────────────────────────────────────────────────────╯

Failure Intelligence:
! Node: /home/bugsfounder/workspace/testing/run_example/requests/03_dependent.toml
Reason: HTTP 401

Actionable Recommendations:
→ Run with -H (Self-Healing) to attempt automatic recovery of failing nodes.
→ Use -v -t to see detailed latency and response diagnostics.

Parallel Execution (-p, --parallel) & Concurrency (-c)

Run independent requests concurrently using graph dependency levels.

rumour run requests/ -p -c 10 -y

How it works: Unlike a naive concurrent runner, Rumour uses a Dependency Graph. When you pass -p:

  1. Dependency Analysis: Rumour analyzes all {{variables}} and determines which requests depend on data extracted from other requests.
  2. Execution Levels: It groups requests into "levels". All requests in Level 1 (no dependencies) fire simultaneously.
  3. Sequential Handoffs: Once Level 1 completes and extracts its data, all requests in Level 2 fire simultaneously, and so on.
  4. Concurrency Limits (-c): If a level has 50 independent requests, the -c 10 flag ensures only 10 active connections are made at a time to prevent overwhelming the target server or hitting OS file descriptor limits.

Data-Driven Testing (--data)

Data-driven testing allows you to automatically iterate a request (or entire workflow) multiple times, seamlessly injecting data from a CSV file directly into your {{variables}}.

For example, given a users.csv file:

user_id,name
1,Alice
2,Bob
3,Charlie

You can execute the workflow iteratively across all 3 rows:

rumour run requests/05_data.toml --data users.csv -y

Output:

--- DATA ITERATION 1/3
GET https://httpbin.org/anything?user=1
✓ SUCCESS: requests/05_data.toml (1842ms)

--- DATA ITERATION 2/3
GET https://httpbin.org/anything?user=2
✓ SUCCESS: requests/05_data.toml (1511ms)

--- DATA ITERATION 3/3
GET https://httpbin.org/anything?user=3
✓ SUCCESS: requests/05_data.toml (1384ms)

[00:00:04] ████████████████████████████████████████ 3/3 ✓ Completed 3 iterations.

How it works: Every column header in your CSV (e.g., user_id) is automatically mapped to a runtime variable. On every iteration, the CLI substitutes {{user_id}} inside the .toml file with the corresponding row's value, allowing you to quickly parameterize large datasets!

Stress Testing (--stress)

When a request file contains a configured [stress_test_data] table pointing to a CSV or JSON dataset, you can trigger automated stress execution using the --stress flag:

rumour run requests/02_create_user.toml --stress

How it works:

  • If the --stress flag is passed, Rumour will automatically load the dataset configured inside the request TOML's [stress_test_data] block and execute iteration runs for each row in the dataset.
  • Without the --stress flag, running the request normally will default to single-request execution, automatically utilizing the first row of the configured dataset for variable resolution. This allows the same request file to be used seamlessly for both single runs and full stress testing without modifications.

Dry Run (--dry-run)

Simulate workflow execution without sending real HTTP requests.

This flag forces the engine to parse the graph, resolve all {{variables}}, evaluate pre-request scripts, and build the final request payloads—but it intentionally skips the final network call. This is incredibly useful for verifying complex variable injections before hitting destructive production APIs.

Combine it with --json to export a full report of what would have been executed:

rumour run requests/01_get.toml --dry-run --json

Output:

{
"total_requests": 1,
"successful": [
{
"id": "requests/01_get.toml",
"duration_ms": 0
}
],
"results": {
"requests/01_get.toml": {
"status": 200,
"body": "[DRY RUN: No body sent]",
"request_sent": {
"method": "GET",
"url": "https://httpbin.org/get",
"headers": {},
"body": null
}
}
}
}

This guarantees your CI pipelines or developers can audit what Rumour is about to do, proving that all dynamic variables (like https://httpbin.org/get) resolved successfully without triggering live endpoints.

Override Variables (-V, --var)

Override variable values at runtime.

rumour run request.toml -V base_url=https://staging.api.com

Extract Variables (-E, --extract)

Dynamically extract data from an HTTP response and save it to a variable, without permanently modifying your .toml file.

The format follows VARIABLE_NAME=SOURCE.PATH:

  • SOURCE: Where to look (json, headers, status, text).
  • PATH: The JSONPath (for json) or the exact key (for headers).

This is heavily used in CI/CD pipelines to grab authentication tokens on the fly and immediately feed them into downstream requests!

For example, imagine you have a requests/ directory containing two files:

  1. 01_login.toml (returns an access token)
  2. 02_get_profile.toml (requires an {{auth_token}} variable in its headers)

You can run the entire directory and dynamically bridge the gap between these two requests at runtime:

rumour run requests/ -E auth_token=json.uuid -v

Output:

GET https://httpbin.org/uuid
✓ SUCCESS: requests/01_login.toml (1931ms)

GET https://httpbin.org/bearer
Header: Authorization: Bearer 4a2b9c3d-8123-4567-abcd-ef0123456789
✓ SUCCESS: requests/02_get_profile.toml (1238ms)

╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 2
│ Successful: 2
│ Failed: 0
│ Skipped: 0
│ Success Rate: 100.0% │
│ Total Time: 3169ms │
╰──────────────────────────────────────────────────────────────────────────╯

What happens:

  1. Rumour executes 01_login.toml.
  2. It parses the JSON response body, extracts the uuid field, and saves it into the global runtime context as {{auth_token}}.
  3. When 02_get_profile.toml executes, it detects the {{auth_token}} variable and successfully injects the dynamic token into its Authorization: Bearer {{auth_token}} header, which you can see verified in the -v (verbose) trace!

You can even chain multiple extractions from different parts of the response simultaneously using multiple -E flags:

rumour run requests/ -E auth_token=json.uuid -E rate_limit=headers.X-RateLimit-Remaining

Environment File (-e, --env-file)

Specify a custom environment file instead of relying on workspace.env.toml.

rumour run requests/01_get.toml -e production.env.toml

Override Headers (--header) & Body (-b, --body)

Add or override request metadata.

rumour run request.toml --header "Authorization: Bearer token123" -b '{"test": true}'

Self-Healing (-H, --heal) & Hard Heal (-X, --hard-heal)

Enable the automated dependency recovery engine.

When Rumour encounters an unexpected error (like a 404 Not Found for a deleted resource), it doesn't just fail. If Self-Healing is enabled, Rumour's dependency graph intelligence kicks in. It will automatically traverse the graph backwards, find the upstream request that generated the missing resource (e.g., a POST request), automatically re-execute it to "heal" the state, and then seamlessly retry your failed request!

  • -H (Soft Heal): Rumour will try to re-execute the upstream dependency using its original variables.
  • -X (Hard Heal): Rumour will forcefully regenerate the randomized variables (like faked emails or UUIDs) of the upstream dependency before re-executing it. This is crucial if the upstream dependency fails on replay due to a 409 Conflict (e.g., trying to recreate a user with an email that already exists in the database).

For a deep dive into the healing graph mechanics, see the Interactive Recovery Flows documentation.

rumour run requests/04_fail.toml -H -X

Auto-Cleanup (-C, --auto-cleanup)

Automatically teardown resources created during your session.

When you run a suite of tests that create data (via POST requests), you often want to delete them afterward to keep your test environment pristine. When -C is enabled, Rumour monitors every successful resource creation during execution, automatically infers the corresponding DELETE endpoint, and executes the teardown phase at the very end of the run!

rumour run requests/ -C

Delay (--delay)

Insert a deliberate pause between each request execution, in milliseconds. This is especially useful when running a large suite of requests against a rate-limited API. Without a delay, Rumour fires requests as fast as possible, which can trigger rate-limiting 429 Too Many Requests errors. Adding a delay keeps your throughput under control.

# Wait 300ms between each request in the suite
rumour run requests/ --delay 300 -y

Output:

GET https://httpbin.org/get
✓ SUCCESS: requests/01_get.toml (1248ms)

# 300ms pause here...

POST https://httpbin.org/post
✓ SUCCESS: requests/02_post.toml (875ms)

# 300ms pause here...

╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 5
│ Successful: 2
│ Failed: 3
│ Skipped: 0
│ Success Rate: 40.0% │
│ Total Time: 24746ms │
╰──────────────────────────────────────────────────────────────────────────╯

Notice how Total Time increases proportionally with the number of requests and the delay value. Without --delay, the same suite completes in under 10 seconds.

Download Directory (-d, --download-dir)

Specify a custom directory where any files downloaded during execution are saved. By default, Rumour saves downloaded files to the current working directory. This flag lets you redirect downloads to a specific folder, which is critical in CI/CD pipelines where you need artifacts saved to a predictable path.

rumour run requests/01_get.toml -d ./downloads -y

Any response body that Rumour identifies as a binary file download (e.g., images, PDFs, zip archives) will be saved to the ./downloads/ directory instead of the default location.

Step Mode (-S, --step) & Interactive (-i, --interactive)

Pause execution and prompt for user interaction before each request. This is invaluable for debugging a failing workflow — you can inspect the state of your environment and decide whether to continue.

You can optionally pass a <NODE_ID> to --step to fast-forward through earlier requests without pausing, and only halt when it reaches that specific node:

# Pause before EVERY request in the suite
rumour run requests/ -S -i

# Run 01 and 02 unattended, only pause before 03
rumour run requests/ -S requests/03_dependent.toml -i

Output (second command):

GET https://httpbin.org/get
✓ SUCCESS: requests/01_get.toml (1248ms)

POST https://httpbin.org/post
✓ SUCCESS: requests/02_post.toml (875ms)

⏸ NEXT: requests/03_dependent.toml
▶ Press Enter to execute, q to quit...

Resume Execution (-r, --resume)

Resume a workflow from where it last left off, using a saved snapshot. If a long-running suite was interrupted halfway through (e.g., by a network failure or Ctrl+C), you don't have to re-run the entire suite from scratch. Rumour saves a checkpoint after each successful request, and --resume picks up from the last successful node.

# First run — fails or is interrupted midway
rumour run requests/ -y

# Resume from where it stopped
rumour run requests/ -r -y

Rumour reads the snapshot file from the run directory and automatically skips nodes that were already marked as successful in the previous run.

Reporting & CI (--junit, --record, --replay)

These flags power Rumour's CI/CD and debugging workflows:

  • --junit <file> — Exports test results as a standard JUnit XML report, consumable by GitHub Actions, Jenkins, GitLab CI, and any other CI system with JUnit support.
  • --record <file> — Records all HTTP responses during this run into a JSON snapshot file. Use this to create a "golden baseline" of your API's behaviour.
  • --replay <file> — Plays back a previously recorded snapshot instead of hitting live endpoints. This makes your test suite completely offline and deterministic—no network calls are made.
# Step 1: Record a live baseline
rumour run requests/ -y --record recording.json

# Step 2: In future CI runs, replay without touching the network
rumour run requests/ -y --replay recording.json

# Step 3: Also export a JUnit report for your CI dashboard
rumour run requests/ -y --junit results.xml

JUnit XML output (results.xml):

<testsuites name="Rumour API Tests" tests="5" failures="3" time="29.349">
<testsuite name="Main Workflow" tests="5" failures="3">
<testcase name="requests/01_get.toml" classname="rumour.workflow" time="3.33"/>
<testcase name="requests/02_post.toml" classname="rumour.workflow" time="5.81"/>
<testcase name="requests/03_dependent.toml" classname="rumour.workflow" time="3.84">
<failure message="HTTP 401"></failure>
</testcase>
</testsuite>
</testsuites>

Replay output — notice Total Time: 1ms because no network calls are made:

╭──────────────────────────────────────────────────────────────────────────╮
│ RUMOUR EXECUTION REPORT │
├──────────────────────────────────────────────────────────────────────────┤
│ Total Requests: 5
│ Successful: 2
│ Failed: 3
│ Skipped: 0
│ Success Rate: 40.0% │
│ Total Time: 1ms │
╰──────────────────────────────────────────────────────────────────────────╯

Performance Profiling (--profile)

Display a per-request network timing breakdown alongside the standard report. Use this to identify whether slowness in your suite is caused by DNS resolution, TCP handshaking, or slow server processing.

Combine with -v (verbose) to see the timing data inline for each request:

rumour run requests/01_get.toml --profile -v -y

Output:

✓ Successful Requests:
- requests/01_get.toml [200] [8949ms] [Proc: 8948ms, Xfer: 0ms]

The [Proc: Xms, Xfer: Xms] columns show how long the server took to process the request versus how long it took to download the response body. A high Proc time indicates a slow backend; a high Xfer time indicates a large response body.

Auto-Confirm (-y, --yes)

Automatically confirm any interactive prompts that Rumour would normally show at startup. By default, if Rumour detects undefined variables or other warnings, it pauses and waits for your confirmation before proceeding. Using -y bypasses all these prompts, making it essential for non-interactive CI/CD pipelines.

# Without -y: Rumour pauses and asks "Continue? [y/N]" at warnings
rumour run requests/

# With -y: All prompts are auto-confirmed, fully unattended
rumour run requests/ -y

Report (--report)

After execution, open the auto-generated HTML dashboard in your default browser. Rumour generates a dashboard.html file inside the .rumour/ subdirectory of your workflow path.

rumour run requests/ -y --report

This is useful for visually reviewing a run's results, timings, and failure details without parsing raw terminal output or JSON.

Concurrency (-c, --concurrency)

Limit the maximum number of requests that can run simultaneously during parallel execution. The default is 20. Use this to avoid overwhelming rate-limited APIs or hitting OS file descriptor limits on large test suites.

# Run in parallel but cap at 5 simultaneous connections
rumour run requests/ -p -c 5 -y

If a dependency level contains 50 independent requests and -c 5 is set, Rumour will process them in batches of 5, waiting for each batch to complete before starting the next.

Exit Codes

The run command only emits two exit codes.

CodeMeaningWhen
0SuccessAll requests passed, or user aborted interactively
1FailureOne or more requests failed, invalid path, unreadable data/replay file