Trigger Chain Runs
Every time a Trigger Chain executes, RTILA X creates a run record that tracks the execution from start to finish. The Trigger Chain Runs page shows the complete history of all runs for a chain, including detailed step-by-step results, variable timelines, and error information.
This is your monitoring dashboard for trigger chains. It tells you what happened, when it happened, what succeeded, what failed, and why.

Opening the Runs Page
Section titled “Opening the Runs Page”- Go to Trigger Chains in the sidebar.
- Select a chain in the list.
- Click Runs in the ribbon toolbar.
The Trigger Chain Runs page opens, showing all runs for the selected chain.
Run Statuses
Section titled “Run Statuses”Every run has one of six statuses:
| Status | Description | Color |
|---|---|---|
| pending | The run has been queued but hasn’t started yet. It’s waiting for the relay engine to pick it up. | Grey |
| running | The chain is currently executing. Steps are being processed. | Blue |
| completed | All steps finished successfully. The chain executed without errors. | Green |
| failed | One or more steps failed. Check the error message and step details for details. | Red |
| cancelled | The run was manually stopped by a user before it completed. | Orange |
| retrying | A step failed and the chain is retrying it (based on the retry policy). | Yellow |
The Run History Table
Section titled “The Run History Table”The runs page displays a table with the following columns:
| Column | Description |
|---|---|
| Status | The run’s current status (see table above) |
| Triggered By | How the run was triggered: manual, scheduler, remote, project_completion, or webhook |
| Correlation ID | A unique identifier (UUID) for tracing this run across logs and systems |
| Started At | The date and time the run started |
| Duration | How long the run took, formatted as Xh Ym Zs |
| Retries | The number of retry attempts made during this run |
| Error | The error message if the run failed. Shows “—” if no error. |
| Actions | Buttons for viewing details, rerunning, and resuming |
Viewing Run Details
Section titled “Viewing Run Details”Click a row in the run history table to expand it. Two tabs appear:
Tab 1: Step Details
Section titled “Tab 1: Step Details”The Step Details tab shows the execution result of each trigger step in the chain.
For each step, you’ll see:
| Field | Description |
|---|---|
| Step Path | The position of the step in the chain (e.g., 0, 1, 2.then.0) |
| Trigger Type | The type of trigger (e.g., rest_api, send_email) |
| Status | Whether this step completed, failed, or was skipped |
| Duration (ms) | How long this step took to execute, in milliseconds |
| Output Variable | The variable name where the step’s result was stored |
Step Status Indicators
Section titled “Step Status Indicators”| Status | Meaning |
|---|---|
| completed | The step executed successfully |
| failed | The step encountered an error |
| skipped | The step was skipped (e.g., the IF condition was false for this branch) |
Tab 2: Variable Timeline
Section titled “Tab 2: Variable Timeline”The Variable Timeline tab shows how variables changed across steps. This is incredibly useful for debugging — you can see exactly what data was available at each point in the chain.
For each variable, you’ll see:
| Field | Description |
|---|---|
| Variable Name | The name of the variable |
| Type | The data type: string, integer, float, boolean, object, array, any, or unknown |
| Step | Which step produced or modified this variable |
| Trigger Type | The type of trigger that produced it |
| Sample Value | A preview of the variable’s value (truncated for display) |
Variable Timeline Features
Section titled “Variable Timeline Features”| Feature | Description |
|---|---|
| Expandable variables | Click a variable to expand and see its full step-by-step history |
| Type badges | Color-coded badges showing the variable type |
| New indicator | A green “new” badge appears when a variable is first created |
| Type changed indicator | An orange “type changed” badge appears when a variable’s type changes between steps |
| Sample values | Truncated previews of the variable’s value at each step |
| Copy button | Click to copy the full sample value to clipboard |
Example Variable Timeline
Section titled “Example Variable Timeline”| Variable | Type | Step | Trigger | Sample |
|---|---|---|---|---|
api_response 🟢 new |
object | Step 0 | rest_api | {"status": 200, "data": [...]} |
record_count 🟢 new |
integer | Step 1 | transform | 247 |
api_response 🟠 type changed |
object | Step 2 | transform | {"status": 200, "processed": true} |
Run Actions
Section titled “Run Actions”Each run row has action buttons:
| Button | Icon | Description |
|---|---|---|
| Rerun | ▶️ | Triggers the chain again with the same configuration |
| Resume | ▶️ | Resumes a failed run from its last checkpoint (only available for failed runs with checkpoints) |
| Expand/Collapse | ▼/▲ | Expands or collapses the run details |
Rerunning a Chain
Section titled “Rerunning a Chain”To rerun a chain from the Runs page:
- Find the run you want to rerun.
- Click the Rerun button (▶️) in the Actions column.
- The chain is queued for execution again.
- A new run record is created with status
pending.
Note: Rerunning creates a completely new run. It does not modify the original run.
Resume from Checkpoint
Section titled “Resume from Checkpoint”When a chain fails, RTILA X saves a checkpoint that records which steps completed successfully. You can resume the chain from where it left off, skipping the steps that already succeeded.
How Resume Works
Section titled “How Resume Works”- A chain fails at Step 3 of 5.
- RTILA X saves a checkpoint recording that Steps 0, 1, and 2 completed.
- You click Resume on the failed run.
- A new run is created that starts from Step 3, skipping Steps 0–2.
- If the resume succeeds, the chain completes.
When Resume Is Available
Section titled “When Resume Is Available”The Resume button only appears when:
- The run’s status is
failed. - The run has checkpoint data (meaning at least one step completed before the failure).
Checkpoint Data
Section titled “Checkpoint Data”The checkpoint stores:
| Field | Description |
|---|---|
| completed_step_index | The index of the last step that completed successfully |
| variables | All variables that were set during the completed steps |
| trigger_results | Results from completed trigger steps |
Example Checkpoint Scenario
Section titled “Example Checkpoint Scenario”Chain: 5 steps (0, 1, 2, 3, 4)Step 0: REST API ✅ completedStep 1: Transform ✅ completedStep 2: Database Insert ✅ completedStep 3: Send Email ❌ FAILED (SMTP server unreachable)Step 4: Not executed
Checkpoint saved: completed_step_index = 2Resume will start from Step 3.Triggered By Values
Section titled “Triggered By Values”The Triggered By column shows how the run was initiated:
| Value | Description |
|---|---|
| manual | A user clicked Run in the RTILA X interface |
| scheduler | The chain was triggered by its schedule |
| remote | The chain was triggered via the remote execution API |
| project_completion | The chain was triggered automatically after a project finished |
| webhook | The chain was triggered by an external webhook request |
Run Duration
Section titled “Run Duration”The Duration column shows how long the run took, formatted as:
| Format | Example | Meaning |
|---|---|---|
Xh Ym Zs |
1h 23m 45s |
1 hour, 23 minutes, 45 seconds |
Ym Zs |
5m 30s |
5 minutes, 30 seconds |
Zs |
45s |
45 seconds |
N/A |
N/A |
Duration not available (run didn’t complete) |
Error Messages
Section titled “Error Messages”When a run fails, the Error column shows the error message. Common error messages include:
| Error | Cause | Solution |
|---|---|---|
Trigger chain run timed out after X hours |
The chain exceeded its timeout setting | Increase the timeout in chain settings, or optimize slow steps |
SMTP server unreachable |
Email server is unreachable | Check SMTP server settings and network connectivity |
API returned 401 Unauthorized |
Invalid API credentials | Check API keys and authentication headers |
Element not found |
A selector didn’t match any element | Check selectors in the trigger configuration |
Connection refused |
Database or service is unreachable | Check server address, port, and firewall settings |
Run History Pagination
Section titled “Run History Pagination”If a chain has many runs, the history is paginated. Use the navigation controls at the bottom of the table to move between pages.
Tips and Best Practices
Section titled “Tips and Best Practices”| Tip | Description |
|---|---|
| Check failed runs regularly | Don’t let failures pile up. Check the Runs page daily. |
| Use the Variable Timeline for debugging | It shows exactly what data was available at each step. |
| Use Step Details to identify failing steps | The step details show which specific step failed and why. |
| Use Resume for transient failures | If a step failed due to a temporary issue (network blip), resume instead of rerunning from scratch. |
| Monitor retry counts | High retry counts indicate systemic issues with a step. |
| Check the Correlation ID in logs | Use the Correlation ID to trace a specific run across system logs. |
| Filter by status mentally | Scan the Status column for red (failed) runs first. |
| Check Duration for slow steps | Long durations indicate slow steps that may need optimization. |
| Use Rerun for configuration fixes | After fixing a step’s configuration, rerun the chain to test. |
| Monitor scheduled runs | Check that scheduled runs are completing successfully. |