improvement(ui): rename user-facing "execution" to "run" (#4176)

* v0.6.29: login improvements, posthog telemetry (#4026)

* feat(posthog): Add tracking on mothership abort (#4023)

Co-authored-by: Theodore Li <theo@sim.ai>

* fix(login): fix captcha headers for manual login  (#4025)

* fix(signup): fix turnstile key loading

* fix(login): fix captcha header passing

* Catch user already exists, remove login form captcha

* improvement(ui): rename user-facing "execution" to "run"

* fix(mothership): remove duplicate handleStopGeneration declaration

* chore: remove verbose comment in cancel route

* fix(ui): missed execution → run renames in search suggestions and error fallback

---------

Co-authored-by: Theodore Li <theodoreqili@gmail.com>

apps/docs/content/docs/en/execution/api.mdx

@@ -6,7 +6,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
 import { Tab, Tabs } from 'fumadocs-ui/components/tabs'
 import { Video } from '@/components/ui/video'
 
-Sim provides a comprehensive external API for querying workflow execution logs and setting up webhooks for real-time notifications when workflows complete.
+Sim provides a comprehensive external API for querying workflow run logs and setting up webhooks for real-time notifications when workflows complete.
 
 ## Authentication
 
@@ -21,7 +21,7 @@ You can generate API keys from the Sim platform and navigate to **Settings**, th
 
 ## Logs API
 
-All API responses include information about your workflow execution limits and usage:
+All API responses include information about your workflow run limits and usage:
 
 ```json
 "limits": {
@@ -48,11 +48,11 @@ All API responses include information about your workflow execution limits and u
 }
 ```
 
-**Note:** Rate limits use a token bucket algorithm. `remaining` can exceed `requestsPerMinute` up to `maxBurst` when you haven't used your full allowance recently, allowing for burst traffic. The rate limits in the response body are for workflow executions. The rate limits for calling this API endpoint are in the response headers (`X-RateLimit-*`).
+**Note:** Rate limits use a token bucket algorithm. `remaining` can exceed `requestsPerMinute` up to `maxBurst` when you haven't used your full allowance recently, allowing for burst traffic. The rate limits in the response body are for workflow runs. The rate limits for calling this API endpoint are in the response headers (`X-RateLimit-*`).
 
 ### Query Logs
 
-Query workflow execution logs with extensive filtering options.
+Query workflow run logs with extensive filtering options.
 
 <Tabs items={['Request', 'Response']}>
   <Tab value="Request">
@@ -70,11 +70,11 @@ Query workflow execution logs with extensive filtering options.
     - `level` - Filter by level: `info`, `error`
     - `startDate` - ISO timestamp for date range start
     - `endDate` - ISO timestamp for date range end
-    - `executionId` - Exact execution ID match
-    - `minDurationMs` - Minimum execution duration in milliseconds
-    - `maxDurationMs` - Maximum execution duration in milliseconds
-    - `minCost` - Minimum execution cost
-    - `maxCost` - Maximum execution cost
+    - `executionId` - Exact run ID match
+    - `minDurationMs` - Minimum run duration in milliseconds
+    - `maxDurationMs` - Maximum run duration in milliseconds
+    - `minCost` - Minimum run cost
+    - `maxCost` - Maximum run cost
     - `model` - Filter by AI model used
 
     **Pagination:**
@@ -213,9 +213,9 @@ Retrieve detailed information about a specific log entry.
   </Tab>
 </Tabs>
 
-### Get Execution Details
+### Get Run Details
 
-Retrieve execution details including the workflow state snapshot.
+Retrieve run details including the workflow state snapshot.
 
 <Tabs items={['Request', 'Response']}>
   <Tab value="Request">
@@ -248,7 +248,7 @@ Retrieve execution details including the workflow state snapshot.
 
 ## Notifications
 
-Get real-time notifications when workflow executions complete via webhook, email, or Slack. Notifications are configured at the workspace level from the Logs page.
+Get real-time notifications when workflow runs complete via webhook, email, or Slack. Notifications are configured at the workspace level from the Logs page.
 
 ### Configuration
 
@@ -256,7 +256,7 @@ Configure notifications from the Logs page by clicking the menu button and selec
 
 **Notification Channels:**
 - **Webhook**: Send HTTP POST requests to your endpoint
-- **Email**: Receive email notifications with execution details
+- **Email**: Receive email notifications with run details
 - **Slack**: Post messages to a Slack channel
 
 **Workflow Selection:**
@@ -269,38 +269,38 @@ Configure notifications from the Logs page by clicking the menu button and selec
 
 **Optional Data:**
 - `includeFinalOutput`: Include the workflow's final output
-- `includeTraceSpans`: Include detailed execution trace spans
+- `includeTraceSpans`: Include detailed trace spans
 - `includeRateLimits`: Include rate limit information (sync/async limits and remaining)
 - `includeUsageData`: Include billing period usage and limits
 
 ### Alert Rules
 
-Instead of receiving notifications for every execution, configure alert rules to be notified only when issues are detected:
+Instead of receiving notifications for every run, configure alert rules to be notified only when issues are detected:
 
 **Consecutive Failures**
-- Alert after X consecutive failed executions (e.g., 3 failures in a row)
-- Resets when an execution succeeds
+- Alert after X consecutive failed runs (e.g., 3 failures in a row)
+- Resets when a run succeeds
 
 **Failure Rate**
 - Alert when failure rate exceeds X% over the last Y hours
-- Requires minimum 5 executions in the window
+- Requires minimum 5 runs in the window
 - Only triggers after the full time window has elapsed
 
 **Latency Threshold**
-- Alert when any execution takes longer than X seconds
+- Alert when any run takes longer than X seconds
 - Useful for catching slow or hanging workflows
 
 **Latency Spike**
-- Alert when execution is X% slower than the average
+- Alert when a run is X% slower than the average
 - Compares against the average duration over the configured time window
-- Requires minimum 5 executions to establish baseline
+- Requires minimum 5 runs to establish baseline
 
 **Cost Threshold**
-- Alert when a single execution costs more than $X
+- Alert when a single run costs more than $X
 - Useful for catching expensive LLM calls
 
 **No Activity**
-- Alert when no executions occur within X hours
+- Alert when no runs occur within X hours
 - Useful for monitoring scheduled workflows that should run regularly
 
 **Error Count**
@@ -317,7 +317,7 @@ For webhooks, additional options are available:
 
 ### Payload Structure
 
-When a workflow execution completes, Sim sends the following payload (via webhook POST, email, or Slack):
+When a workflow run completes, Sim sends the following payload (via webhook POST, email, or Slack):
 
 ```json
 {
@@ -456,7 +456,7 @@ Failed webhook deliveries are retried with exponential backoff and jitter:
 - Deliveries timeout after 30 seconds
 
 <Callout type="info">
-  Webhook deliveries are processed asynchronously and don't affect workflow execution performance.
+  Webhook deliveries are processed asynchronously and don't affect workflow run performance.
 </Callout>
 
 ## Best Practices
@@ -596,11 +596,11 @@ app.listen(3000, () => {
 import { FAQ } from '@/components/ui/faq'
 
 <FAQ items={[
-  { question: "How do I trigger async execution via the API?", answer: "Set the X-Execution-Mode header to 'async' on your POST request to /api/workflows/{id}/execute. The API returns a 202 response with a jobId, executionId, and a statusUrl you can poll to check when the job completes. Async mode does not support draft state, workflow overrides, or selective output options." },
+  { question: "How do I trigger an async run via the API?", answer: "Set the X-Execution-Mode header to 'async' on your POST request to /api/workflows/{id}/execute. The API returns a 202 response with a jobId, executionId, and a statusUrl you can poll to check when the job completes. Async mode does not support draft state, workflow overrides, or selective output options." },
   { question: "What authentication methods does the API support?", answer: "The API supports two authentication methods: API keys passed in the x-api-key header, and session-based authentication for logged-in users. API keys can be generated from Settings > Sim Keys in the platform. Workflows with public API access enabled can also be called without authentication." },
   { question: "How does the webhook retry policy work?", answer: "Failed webhook deliveries are retried up to 5 times with exponential backoff: 5 seconds, 15 seconds, 1 minute, 3 minutes, and 10 minutes, plus up to 10% jitter. Only HTTP 5xx and 429 responses trigger retries. Each delivery times out after 30 seconds." },
-  { question: "What rate limits apply to the Logs API?", answer: "Rate limits use a token bucket algorithm. Free plans get 30 requests/minute with 60 burst capacity, Pro gets 100/200, Team gets 200/400, and Enterprise gets 500/1000. These are separate from workflow execution rate limits, which are shown in the response body." },
+  { question: "What rate limits apply to the Logs API?", answer: "Rate limits use a token bucket algorithm. Free plans get 30 requests/minute with 60 burst capacity, Pro gets 100/200, Team gets 200/400, and Enterprise gets 500/1000. These are separate from workflow run rate limits, which are shown in the response body." },
   { question: "How do I verify that a webhook is from Sim?", answer: "Configure a webhook secret when setting up notifications. Sim signs each delivery with HMAC-SHA256 using the format 't={timestamp},v1={signature}' in the sim-signature header. Compute the HMAC of '{timestamp}.{body}' with your secret and compare it to the signature value." },
   { question: "What alert rules are available for notifications?", answer: "You can configure alerts for consecutive failures, failure rate thresholds, latency thresholds, latency spikes (percentage above average), cost thresholds, no-activity periods, and error counts within a time window. All alert types include a 1-hour cooldown to prevent notification spam." },
-  { question: "Can I filter which executions trigger notifications?", answer: "Yes. You can filter notifications by specific workflows (or select all), log level (info or error), and trigger type (api, webhook, schedule, manual, chat). You can also choose whether to include final output, trace spans, rate limits, and usage data in the notification payload." },
+  { question: "Can I filter which runs trigger notifications?", answer: "Yes. You can filter notifications by specific workflows (or select all), log level (info or error), and trigger type (api, webhook, schedule, manual, chat). You can also choose whether to include final output, trace spans, rate limits, and usage data in the notification payload." },
 ]} />

apps/docs/content/docs/en/execution/basics.mdx

@@ -6,7 +6,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
 import { Card, Cards } from 'fumadocs-ui/components/card'
 import { Image } from '@/components/ui/image'
 
-Understanding how workflows execute in Sim is key to building efficient and reliable automations. The execution engine automatically handles dependencies, concurrency, and data flow to ensure your workflows run smoothly and predictably.
+Understanding how workflows run in Sim is key to building efficient and reliable automations. The execution engine automatically handles dependencies, concurrency, and data flow to ensure your workflows run smoothly and predictably.
 
 ## How Workflows Execute
 
@@ -14,7 +14,7 @@ Sim's execution engine processes workflows intelligently by analyzing dependenci
 
 ### Concurrent Execution by Default
 
-Multiple blocks run concurrently when they don't depend on each other. This parallel execution dramatically improves performance without requiring manual configuration.
+Multiple blocks run concurrently when they don't depend on each other. This dramatically improves performance without requiring manual configuration.
 
 <Image
   src="/static/execution/concurrency.png"
@@ -49,7 +49,7 @@ Workflows can branch in multiple directions using routing blocks. The execution
   height={500}
 />
 
-This workflow demonstrates how execution can follow different paths based on conditions or AI decisions, with each path executing independently.
+This workflow demonstrates how a run can follow different paths based on conditions or AI decisions, with each path running independently.
 
 ## Block Types
 
@@ -57,7 +57,7 @@ Sim provides different types of blocks that serve specific purposes in your work
 
 <Cards>
   <Card title="Triggers" href="/triggers">
-    **Starter blocks** initiate workflows and **Webhook blocks** respond to external events. Every workflow needs a trigger to begin execution.
+    **Starter blocks** initiate workflows and **Webhook blocks** respond to external events. Every workflow needs a trigger to begin a run.
   </Card>
   
   <Card title="Processing Blocks" href="/blocks">
@@ -73,37 +73,37 @@ Sim provides different types of blocks that serve specific purposes in your work
   </Card>
 </Cards>
 
-All blocks execute automatically based on their dependencies - you don't need to manually manage execution order or timing.
+All blocks run automatically based on their dependencies - you don't need to manually manage run order or timing.
 
-## Execution Monitoring
+## Run Monitoring
 
-When workflows run, Sim provides real-time visibility into the execution process:
+When workflows run, Sim provides real-time visibility into the process:
 
-- **Live Block States**: See which blocks are currently executing, completed, or failed
-- **Execution Logs**: Detailed logs appear in real-time showing inputs, outputs, and any errors
-- **Performance Metrics**: Track execution time and costs for each block
-- **Path Visualization**: Understand which execution paths were taken through your workflow
+- **Live Block States**: See which blocks are currently running, completed, or failed
+- **Run Logs**: Detailed logs appear in real-time showing inputs, outputs, and any errors
+- **Performance Metrics**: Track run time and costs for each block
+- **Path Visualization**: Understand which paths were taken through your workflow
 
 <Callout type="info">
-  All execution details are captured and available for review even after workflows complete, helping with debugging and optimization.
+  All run details are captured and available for review even after workflows complete, helping with debugging and optimization.
 </Callout>
 
-## Key Execution Principles
+## Key Principles
 
 Understanding these core principles will help you build better workflows:
 
 1. **Dependency-Based Execution**: Blocks only run when all their dependencies have completed
 2. **Automatic Parallelization**: Independent blocks run concurrently without configuration
 3. **Smart Data Flow**: Outputs flow automatically to connected blocks
-4. **Error Handling**: Failed blocks stop their execution path but don't affect independent paths
-5. **Response Blocks as Exit Points**: When a Response block executes, the entire workflow stops and the API response is sent immediately. Multiple Response blocks can exist on different branches — the first one to execute wins
-6. **State Persistence**: All block outputs and execution details are preserved for debugging
-7. **Cycle Protection**: Workflows that call other workflows (via Workflow blocks, MCP tools, or API blocks) are tracked with a call chain. If the chain exceeds 25 hops, execution is stopped to prevent infinite loops
+4. **Error Handling**: Failed blocks stop their run path but don't affect independent paths
+5. **Response Blocks as Exit Points**: When a Response block runs, the entire workflow stops and the API response is sent immediately. Multiple Response blocks can exist on different branches — the first one to run wins
+6. **State Persistence**: All block outputs and run details are preserved for debugging
+7. **Cycle Protection**: Workflows that call other workflows (via Workflow blocks, MCP tools, or API blocks) are tracked with a call chain. If the chain exceeds 25 hops, the run is stopped to prevent infinite loops
 
 ## Next Steps
 
 Now that you understand execution basics, explore:
 - **[Block Types](/blocks)** - Learn about specific block capabilities
-- **[Logging](/execution/logging)** - Monitor workflow executions and debug issues
+- **[Logging](/execution/logging)** - Monitor workflow runs and debug issues
 - **[Cost Calculation](/execution/costs)** - Understand and optimize workflow costs
 - **[Triggers](/triggers)** - Set up different ways to run your workflows

apps/docs/content/docs/en/execution/costs.mdx

@@ -6,7 +6,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
 import { Tab, Tabs } from 'fumadocs-ui/components/tabs'
 import { Image } from '@/components/ui/image'
 
-Sim automatically calculates costs for all workflow executions, providing transparent pricing based on AI model usage and execution charges. Understanding these costs helps you optimize workflows and manage your budget effectively.
+Sim automatically calculates costs for all workflow runs, providing transparent pricing based on AI model usage and run charges. Understanding these costs helps you optimize workflows and manage your budget effectively.
 
 ## Credits
 
@@ -16,18 +16,18 @@ All plan limits, usage meters, and billing thresholds are displayed in credits t
 
 ## How Costs Are Calculated
 
-Every workflow execution includes two cost components:
+Every workflow run includes two cost components:
 
-**Base Execution Charge**: 1 credit ($0.005) per execution
+**Base Run Charge**: 1 credit ($0.005) per run
 
 **AI Model Usage**: Variable cost based on token consumption
 ```javascript
 modelCost = (inputTokens × inputPrice + outputTokens × outputPrice) / 1,000,000
-totalCredits = baseExecutionCharge + modelCost × 200
+totalCredits = baseRunCharge + modelCost × 200
 ```
 
 <Callout type="info">
-  AI model prices are per million tokens. The calculation divides by 1,000,000 to get the actual cost. Workflows without AI blocks only incur the base execution charge.
+  AI model prices are per million tokens. The calculation divides by 1,000,000 to get the actual cost. Workflows without AI blocks only incur the base run charge.
 </Callout>
 
 ## Model Breakdown in Logs
@@ -48,7 +48,7 @@ The model breakdown shows:
 - **Token Usage**: Input and output token counts for each model
 - **Cost Breakdown**: Individual costs per model and operation
 - **Model Distribution**: Which models were used and how many times
-- **Total Cost**: Aggregate cost for the entire workflow execution
+- **Total Cost**: Aggregate cost for the entire workflow run
 
 ## Pricing Options
 
@@ -330,18 +330,18 @@ Max (individual) shares the same rate limits as team plans. Team plans (Pro or M
 
 Team plans (Pro or Max for Teams) use 500 GB.
 
-### Execution Time Limits
+### Run Time Limits
 
 | Plan | Sync | Async |
 |------|------|-------|
 | **Free** | 5 minutes | 90 minutes |
 | **Pro / Max / Team / Enterprise** | 50 minutes | 90 minutes |
 
-**Sync executions** run immediately and return results directly. These are triggered via the API with `async: false` (default) or through the UI.
-**Async executions** (triggered via API with `async: true`, webhooks, or schedules) run in the background.
+**Sync runs** complete immediately and return results directly. These are triggered via the API with `async: false` (default) or through the UI.
+**Async runs** (triggered via API with `async: true`, webhooks, or schedules) run in the background.
 
 <Callout type="info">
-  If a workflow exceeds its time limit, it will be terminated and marked as failed with a timeout error. Design long-running workflows to use async execution or break them into smaller workflows.
+  If a workflow exceeds its time limit, it will be terminated and marked as failed with a timeout error. Design long-running workflows to use async runs or break them into smaller workflows.
 </Callout>
 
 ## Billing Model
@@ -452,18 +452,18 @@ curl -X GET -H "X-API-Key: YOUR_API_KEY" -H "Content-Type: application/json" htt
 ## Next Steps
 
 - Review your current usage in [Settings → Subscription](https://sim.ai/settings/subscription)
-- Learn about [Logging](/execution/logging) to track execution details
+- Learn about [Logging](/execution/logging) to track run details
 - Explore the [External API](/execution/api) for programmatic cost monitoring
 - Check out [workflow optimization techniques](/blocks) to reduce costs
 
 import { FAQ } from '@/components/ui/faq'
 
 <FAQ items={[
-  { question: "How much does a single workflow execution cost?", answer: "Every execution incurs a base charge of 1 credit ($0.005). On top of that, any AI model usage is billed based on token consumption. Workflows that do not use AI blocks only pay the base execution charge." },
+  { question: "How much does a single workflow run cost?", answer: "Every run incurs a base charge of 1 credit ($0.005). On top of that, any AI model usage is billed based on token consumption. Workflows that do not use AI blocks only pay the base run charge." },
   { question: "What is the credit-to-dollar conversion rate?", answer: "1 credit equals $0.005. All plan limits, usage meters, and billing thresholds in the Sim UI are displayed in credits." },
   { question: "Do unused daily refresh credits carry over?", answer: "No. Daily refresh credits reset every 24 hours and do not accumulate. If you do not use them within the day, they are lost." },
-  { question: "What happens when I exceed my plan's credit limit?", answer: "By default, your usage is capped at your plan's included credits and executions will stop. If you enable on-demand billing or manually raise your usage limit in Settings, you can continue running workflows and pay for the overage at the end of the billing period." },
+  { question: "What happens when I exceed my plan's credit limit?", answer: "By default, your usage is capped at your plan's included credits and runs will stop. If you enable on-demand billing or manually raise your usage limit in Settings, you can continue running workflows and pay for the overage at the end of the billing period." },
   { question: "How does the 1.1x hosted model multiplier work?", answer: "When you use Sim's hosted API keys (instead of bringing your own), a 1.1x multiplier is applied to the base model pricing for Agent blocks. This covers infrastructure and API management costs. You can avoid this multiplier by using your own API keys via the BYOK feature." },
-  { question: "Are there any free options for AI models?", answer: "Yes. If you run local models through Ollama or VLLM, there are no API costs for those model calls. You still pay the base execution charge of 1 credit per execution." },
+  { question: "Are there any free options for AI models?", answer: "Yes. If you run local models through Ollama or VLLM, there are no API costs for those model calls. You still pay the base run charge of 1 credit per run." },
   { question: "When does threshold billing trigger?", answer: "When on-demand billing is enabled and your unbilled overage reaches $50, Sim automatically bills the full unbilled amount. This spreads large charges throughout the month instead of accumulating one large bill at period end." },
 ]} />

apps/docs/content/docs/en/execution/files.mdx

@@ -156,7 +156,7 @@ Use `url` for direct downloads or `base64` for inline processing.
 - **Dropbox** - Dropbox file operations
 
 <Callout type="info">
-  Files are automatically available to downstream blocks. The execution engine handles all file transfer and format conversion.
+  Files are automatically available to downstream blocks. The engine handles all file transfer and format conversion.
 </Callout>
 
 ## Best Practices
@@ -165,15 +165,15 @@ Use `url` for direct downloads or `base64` for inline processing.
 
 2. **Check file types** - Ensure the file type matches what the receiving block expects. The Vision block needs images, the File block handles documents.
 
-3. **Consider file size** - Large files increase execution time. For very large files, consider using storage blocks (S3, Supabase) for intermediate storage.
+3. **Consider file size** - Large files increase run time. For very large files, consider using storage blocks (S3, Supabase) for intermediate storage.
 
 import { FAQ } from '@/components/ui/faq'
 
 <FAQ items={[
-  { question: "What is the maximum file size for uploads?", answer: "The maximum file size for files processed during workflow execution is 20 MB. Files exceeding this limit will be rejected with an error indicating the actual file size. For larger files, use storage blocks like S3 or Supabase for intermediate storage." },
+  { question: "What is the maximum file size for uploads?", answer: "The maximum file size for files processed during a workflow run is 20 MB. Files exceeding this limit will be rejected with an error indicating the actual file size. For larger files, use storage blocks like S3 or Supabase for intermediate storage." },
   { question: "What file input formats are supported via the API?", answer: "When triggering a workflow via API, you can send files as base64-encoded data (using a data URI with the format 'data:{mime};base64,{data}') or as a URL pointing to a publicly accessible file. In both cases, include the file name and MIME type in the request." },
   { question: "How are files passed between blocks internally?", answer: "Files are represented as standardized UserFile objects with name, url, base64, type, and size properties. Most blocks accept the full file object and extract what they need automatically, so you typically pass the entire object rather than individual properties." },
   { question: "Which blocks can output files?", answer: "Gmail outputs email attachments, Slack outputs downloaded files, TTS generates audio files, Video Generator and Image Generator produce media files. Storage blocks like S3, Supabase, Google Drive, and Dropbox can also retrieve files for use in downstream blocks." },
   { question: "Do I need to extract base64 or URL from file objects manually?", answer: "No. Most blocks accept the full file object and handle the format conversion automatically. Simply pass the entire file reference (e.g., <gmail.attachments[0]>) and the receiving block will extract the data it needs." },
-  { question: "How do file fields work in the Start block's input format?", answer: "When you define a field with type 'file[]' in the Start block's input format, the execution engine automatically processes incoming file data (base64 or URL) and uploads it to storage, converting it into UserFile objects before the workflow runs." },
+  { question: "How do file fields work in the Start block's input format?", answer: "When you define a field with type 'file[]' in the Start block's input format, the engine automatically processes incoming file data (base64 or URL) and uploads it to storage, converting it into UserFile objects before the workflow runs." },
 ]} />

apps/docs/content/docs/en/execution/index.mdx

@@ -7,10 +7,10 @@ import { Card, Cards } from 'fumadocs-ui/components/card'
 import { Image } from '@/components/ui/image'
 import { FAQ } from '@/components/ui/faq'
 
-Sim's execution engine brings your workflows to life by processing blocks in the correct order, managing data flow, and handling errors gracefully, so you can understand exactly how workflows are executed in Sim.
+Sim's execution engine brings your workflows to life by processing blocks in the correct order, managing data flow, and handling errors gracefully, so you can understand exactly how workflows run in Sim.
 
 <Callout type="info">
-  Every workflow execution follows a deterministic path based on your block connections and logic, ensuring predictable and reliable results.
+  Every workflow run follows a deterministic path based on your block connections and logic, ensuring predictable and reliable results.
 </Callout>
 
 ## Documentation Overview
@@ -22,33 +22,33 @@ Sim's execution engine brings your workflows to life by processing blocks in the
   </Card>
 
   <Card title="Logging" href="/execution/logging">
-    Monitor workflow executions with comprehensive logging and real-time visibility
+    Monitor workflow runs with comprehensive logging and real-time visibility
   </Card>
-  
+
   <Card title="Cost Calculation" href="/execution/costs">
-    Understand how workflow execution costs are calculated and optimized
+    Understand how workflow run costs are calculated and optimized
   </Card>
-  
+
   <Card title="External API" href="/execution/api">
-    Access execution logs and set up webhooks programmatically via REST API
+    Access run logs and set up webhooks programmatically via REST API
   </Card>
 </Cards>
 
 ## Key Concepts
 
 ### Topological Execution
-Blocks execute in dependency order, similar to how a spreadsheet recalculates cells. The execution engine automatically determines which blocks can run based on completed dependencies.
+Blocks run in dependency order, similar to how a spreadsheet recalculates cells. The execution engine automatically determines which blocks can run based on completed dependencies.
 
 ### Path Tracking
-The engine actively tracks execution paths through your workflow. Router and Condition blocks dynamically update these paths, ensuring only relevant blocks execute.
+The engine actively tracks run paths through your workflow. Router and Condition blocks dynamically update these paths, ensuring only relevant blocks run.
 
 ### Layer-Based Processing
 Instead of executing blocks one-by-one, the engine identifies layers of blocks that can run in parallel, optimizing performance for complex workflows.
 
-### Execution Context
-Each workflow maintains a rich context during execution containing:
+### Run Context
+Each workflow maintains a rich context during a run containing:
 - Block outputs and states
-- Active execution paths
+- Active run paths
 - Loop and parallel iteration tracking
 - Environment variables
 - Routing decisions
@@ -56,7 +56,7 @@ Each workflow maintains a rich context during execution containing:
 
 ## Deployment Snapshots
 
-API, Chat, Schedule, and Webhook executions run against the workflow’s active deployment snapshot. Manual runs from the editor execute the current draft canvas state, letting you test changes before deploying. Publish a new deployment whenever you change the canvas so every trigger uses the updated version.
+API, Chat, Schedule, and Webhook runs use the workflow’s active deployment snapshot. Manual runs from the editor use the current draft canvas state, letting you test changes before deploying. Publish a new deployment whenever you change the canvas so every trigger uses the updated version.
 
 <div className='flex justify-center my-6'>
   <Image
@@ -70,9 +70,9 @@ API, Chat, Schedule, and Webhook executions run against the workflow’s active
 
 The Deploy modal keeps a full version history—inspect any snapshot, compare it against your draft, and promote or roll back with one click when you need to restore a prior release.
 
-## Programmatic Execution
+## Programmatic Access
 
-Execute workflows from your applications using our official SDKs:
+Run workflows from your applications using our official SDKs:
 
 ```bash
 # TypeScript/JavaScript
@@ -107,21 +107,21 @@ const result = await client.executeWorkflow('workflow-id', {
 - Use parallel execution for independent operations
 - Cache results with Memory blocks when appropriate
 
-### Monitor Executions
+### Monitor Runs
 - Review logs regularly to understand performance patterns
 - Track costs for AI model usage
 - Use workflow snapshots to debug issues
 
 ## What's Next?
 
-Start with [Execution Basics](/execution/basics) to understand how workflows run, then explore [Logging](/execution/logging) to monitor your executions and [Cost Calculation](/execution/costs) to optimize your spending.
+Start with [Execution Basics](/execution/basics) to understand how workflows run, then explore [Logging](/execution/logging) to monitor your runs and [Cost Calculation](/execution/costs) to optimize your spending.
 
 <FAQ items={[
-  { question: "What are the execution timeout limits?", answer: "Synchronous executions (API, chat) have a default timeout of 5 minutes on the Free plan and 50 minutes on Pro, Team, and Enterprise plans. Asynchronous executions (schedules, webhooks) allow up to 90 minutes across all plans. These limits are configurable by the platform administrator." },
+  { question: "What are the run timeout limits?", answer: "Synchronous runs (API, chat) have a default timeout of 5 minutes on the Free plan and 50 minutes on Pro, Team, and Enterprise plans. Asynchronous runs (schedules, webhooks) allow up to 90 minutes across all plans. These limits are configurable by the platform administrator." },
   { question: "How does parallel execution work?", answer: "The engine identifies layers of blocks with no dependencies on each other and runs them concurrently. Within loops and parallel blocks, the engine supports up to 20 parallel branches by default and up to 1,000 loop iterations. Nested subflows (loops inside parallels, or vice versa) are supported up to 10 levels deep." },
-  { question: "Can I cancel a running execution?", answer: "Yes. The engine supports cancellation through an abort signal mechanism. When you cancel an execution, the engine checks for cancellation between block executions (at roughly 500ms intervals when using Redis-backed cancellation). Any in-progress blocks complete, and the execution returns with a cancelled status." },
-  { question: "What is a deployment snapshot?", answer: "A deployment snapshot is a frozen copy of your workflow at the time you click Deploy. Trigger-based executions (API, chat, schedule, webhook) run against the active snapshot, not your draft canvas. Manual runs from the editor execute the current draft canvas state, so you can test changes before deploying. You can view, compare, and roll back snapshots from the Deploy modal." },
-  { question: "How are execution costs calculated?", answer: "Costs are tracked per block based on the AI model used. Each block log records input tokens, output tokens, and the computed cost using the model's pricing. The total workflow cost is the sum of all block-level costs for that execution. You can review costs in the execution logs." },
-  { question: "What happens when a block fails during execution?", answer: "When a block throws an error, the engine captures the error message in the block log, finalizes any incomplete logs with timing data, and halts the execution with a failure status. If the failing block has an error output handle connected to another block, that error path is followed instead of halting entirely." },
-  { question: "Can I re-run part of a workflow without starting from scratch?", answer: "Yes. The run-from-block feature lets you select a specific block and re-execute from that point. The engine computes which upstream blocks need to be re-run (the dirty set) and preserves cached outputs from blocks that have not changed, so only the affected portion of the workflow re-executes." },
+  { question: "Can I cancel a running workflow?", answer: "Yes. The engine supports cancellation through an abort signal mechanism. When you cancel a run, the engine checks for cancellation between blocks (at roughly 500ms intervals when using Redis-backed cancellation). Any in-progress blocks complete, and the run returns with a cancelled status." },
+  { question: "What is a deployment snapshot?", answer: "A deployment snapshot is a frozen copy of your workflow at the time you click Deploy. Trigger-based runs (API, chat, schedule, webhook) use the active snapshot, not your draft canvas. Manual runs from the editor use the current draft canvas state, so you can test changes before deploying. You can view, compare, and roll back snapshots from the Deploy modal." },
+  { question: "How are run costs calculated?", answer: "Costs are tracked per block based on the AI model used. Each block log records input tokens, output tokens, and the computed cost using the model's pricing. The total workflow cost is the sum of all block-level costs for that run. You can review costs in the run logs." },
+  { question: "What happens when a block fails during a run?", answer: "When a block throws an error, the engine captures the error message in the block log, finalizes any incomplete logs with timing data, and halts the run with a failure status. If the failing block has an error output handle connected to another block, that error path is followed instead of halting entirely." },
+  { question: "Can I re-run part of a workflow without starting from scratch?", answer: "Yes. The run-from-block feature lets you select a specific block and re-run from that point. The engine computes which upstream blocks need to be re-run (the dirty set) and preserves cached outputs from blocks that have not changed, so only the affected portion of the workflow re-runs." },
 ]} />

apps/docs/content/docs/en/execution/logging.mdx

@@ -6,7 +6,7 @@ import { Callout } from 'fumadocs-ui/components/callout'
 import { Tab, Tabs } from 'fumadocs-ui/components/tabs'
 import { Image } from '@/components/ui/image'
 
-Sim provides comprehensive logging for all workflow executions, giving you complete visibility into how your workflows run, what data flows through them, and where issues might occur.
+Sim provides comprehensive logging for all workflow runs, giving you complete visibility into how your workflows run, what data flows through them, and where issues might occur.
 
 ## Logging System
 
@@ -14,7 +14,7 @@ Sim offers two complementary logging interfaces to match different workflows and
 
 ### Real-Time Console
 
-During manual or chat workflow execution, logs appear in real-time in the Console panel on the right side of the workflow editor:
+During manual or chat workflow runs, logs appear in real-time in the Console panel on the right side of the workflow editor:
 
 <div className="flex justify-center">
   <Image
@@ -27,14 +27,14 @@ During manual or chat workflow execution, logs appear in real-time in the Consol
 </div>
 
 The console shows:
-- Block execution progress with active block highlighting
+- Block progress with active block highlighting
 - Real-time outputs as blocks complete
-- Execution timing for each block
+- Timing for each block
 - Success/error status indicators
 
 ### Logs Page
 
-All workflow executions—whether triggered manually, via API, Chat, Schedule, or Webhook—are logged to the dedicated Logs page:
+All workflow runs—whether triggered manually, via API, Chat, Schedule, or Webhook—are logged to the dedicated Logs page:
 
 <div className="flex justify-center">
   <Image
@@ -72,7 +72,7 @@ View the complete data flow for each block with tabs to switch between:
 
 <Tabs items={['Output', 'Input']}>
   <Tab>
-    **Output Tab** shows the block's execution result:
+    **Output Tab** shows the block's result:
     - Structured data with JSON formatting
     - Markdown rendering for AI-generated content
     - Copy button for easy data extraction
@@ -87,17 +87,17 @@ View the complete data flow for each block with tabs to switch between:
   </Tab>
 </Tabs>
 
-### Execution Timeline
+### Run Timeline
 
-For workflow-level logs, view detailed execution metrics:
+For workflow-level logs, view detailed run metrics:
 - Start and end timestamps
 - Total workflow duration
-- Individual block execution times
+- Individual block run times
 - Performance bottleneck identification
 
 ## Workflow Snapshots
 
-For any logged execution, click "View Snapshot" to see the exact workflow state at execution time:
+For any logged run, click "View Snapshot" to see the exact workflow state at the time of the run:
 
 <div className="flex justify-center">
   <Image
@@ -111,12 +111,12 @@ For any logged execution, click "View Snapshot" to see the exact workflow state
 
 The snapshot provides:
 - Frozen canvas showing the workflow structure
-- Block states and connections as they were during execution
+- Block states and connections as they were during the run
 - Click any block to see its inputs and outputs
 - Useful for debugging workflows that have since been modified
 
 <Callout type="info">
-  Workflow snapshots are only available for executions after the enhanced logging system was introduced. Older migrated logs show a "Logged State Not Found" message.
+  Workflow snapshots are only available for runs after the enhanced logging system was introduced. Older migrated logs show a "Logged State Not Found" message.
 </Callout>
 
 ## Log Retention
@@ -134,11 +134,11 @@ The snapshot provides:
 ### For Production
 - Monitor the Logs page regularly for errors or performance issues
 - Set up filters to focus on specific workflows or time periods
-- Use live mode during critical deployments to watch executions in real-time
+- Use live mode during critical deployments to watch runs in real-time
 
 ### For Debugging
-- Always check the execution timeline to identify slow blocks
-- Compare inputs between working and failing executions
+- Always check the run timeline to identify slow blocks
+- Compare inputs between working and failing runs
 - Use workflow snapshots to see the exact state when issues occurred
 
 ## Next Steps
@@ -150,10 +150,10 @@ The snapshot provides:
 import { FAQ } from '@/components/ui/faq'
 
 <FAQ items={[
-  { question: "How long are execution logs retained?", answer: "Free plans retain logs for 7 days — after that, logs are archived to cloud storage and deleted from the database. Pro, Team, and Enterprise plans retain logs indefinitely with no automatic cleanup." },
-  { question: "What data is captured in each execution log?", answer: "Each log entry includes the execution ID, workflow ID, trigger type, start and end timestamps, total duration in milliseconds, cost breakdown (total cost, token counts, and per-model breakdowns), execution data with trace spans, final output, and any associated files. The log details sidebar lets you inspect block-level inputs and outputs." },
+  { question: "How long are run logs retained?", answer: "Free plans retain logs for 7 days — after that, logs are archived to cloud storage and deleted from the database. Pro, Team, and Enterprise plans retain logs indefinitely with no automatic cleanup." },
+  { question: "What data is captured in each run log?", answer: "Each log entry includes the run ID, workflow ID, trigger type, start and end timestamps, total duration in milliseconds, cost breakdown (total cost, token counts, and per-model breakdowns), run data with trace spans, final output, and any associated files. The log details sidebar lets you inspect block-level inputs and outputs." },
   { question: "Are API keys visible in the logs?", answer: "No. API keys and credentials are automatically redacted in the log input tab for security. You can safely inspect block inputs without exposing sensitive values." },
-  { question: "What is a workflow snapshot?", answer: "A workflow snapshot is a frozen copy of the workflow's structure (blocks, connections, and configuration) captured at execution time. It lets you see the exact state of the workflow when a particular execution ran, which is useful for debugging workflows that have been modified since the execution." },
-  { question: "Can I access logs programmatically?", answer: "Yes. The External API provides endpoints to query logs with filtering by workflow, time range, trigger type, duration, cost, and model. You can also set up webhook, email, or Slack notifications for real-time alerts when executions complete." },
-  { question: "What does Live mode do on the Logs page?", answer: "Live mode automatically refreshes the Logs page in real-time so new execution entries appear as they are logged, without requiring manual page refreshes. This is useful during deployments or when monitoring active workflows." },
+  { question: "What is a workflow snapshot?", answer: "A workflow snapshot is a frozen copy of the workflow's structure (blocks, connections, and configuration) captured at the time of a run. It lets you see the exact state of the workflow when a particular run happened, which is useful for debugging workflows that have been modified since." },
+  { question: "Can I access logs programmatically?", answer: "Yes. The External API provides endpoints to query logs with filtering by workflow, time range, trigger type, duration, cost, and model. You can also set up webhook, email, or Slack notifications for real-time alerts when runs complete." },
+  { question: "What does Live mode do on the Logs page?", answer: "Live mode automatically refreshes the Logs page in real-time so new log entries appear as they are recorded, without requiring manual page refreshes. This is useful during deployments or when monitoring active workflows." },
 ]} />

apps/docs/content/docs/en/triggers/index.mdx

@@ -29,7 +29,7 @@ Use the Start block for everything originating from the editor, deploy-to-API, o
     Receive external webhook payloads
   </Card>
   <Card title="Schedule" href="/triggers/schedule">
-    Cron or interval based execution
+    Cron or interval based runs
   </Card>
   <Card title="RSS Feed" href="/triggers/rss">
     Monitor RSS and Atom feeds for new content
@@ -59,17 +59,17 @@ Use the Start block for everything originating from the editor, deploy-to-API, o
 
 > Deployments power every trigger. Update the workflow, redeploy, and all trigger entry points pick up the new snapshot. Learn more in [Execution → Deployment Snapshots](/execution).
 
-## Manual Execution Priority
+## Manual Run Priority
 
-When you click **Run** in the editor, Sim automatically selects which trigger to execute based on the following priority order:
+When you click **Run** in the editor, Sim automatically selects which trigger to run based on the following priority order:
 
 1. **Start Block** (highest priority)
 2. **Schedule Triggers**
 3. **External Triggers** (webhooks, integrations like Slack, Gmail, Airtable, etc.)
 
-If your workflow has multiple triggers, the highest priority trigger will be executed. For example, if you have both a Start block and a Webhook trigger, clicking Run will execute the Start block.
+If your workflow has multiple triggers, the highest priority trigger will be used. For example, if you have both a Start block and a Webhook trigger, clicking Run will use the Start block.
 
-**External triggers with mock payloads**: When external triggers (webhooks and integrations) are executed manually, Sim automatically generates mock payloads based on the trigger's expected data structure. This ensures downstream blocks can resolve variables correctly during testing.
+**External triggers with mock payloads**: When external triggers (webhooks and integrations) are run manually, Sim automatically generates mock payloads based on the trigger's expected data structure. This ensures downstream blocks can resolve variables correctly during testing.
 
 ## Email Polling Groups
 
@@ -94,10 +94,10 @@ Invitees receive an email with a link to connect their account. Once connected,
 When configuring an email trigger, select your polling group from the credentials dropdown instead of an individual account. The system creates webhooks for each member and routes all emails through your workflow.
 
 <FAQ items={[
-  { question: "Can I have multiple triggers on the same workflow?", answer: "Yes, a workflow can have multiple triggers (for example, a Start block and a Webhook trigger). When you click Run in the editor, Sim executes the highest-priority trigger: Start block first, then Schedule, then external triggers like webhooks. Each trigger type can also fire independently when its event occurs." },
+  { question: "Can I have multiple triggers on the same workflow?", answer: "Yes, a workflow can have multiple triggers (for example, a Start block and a Webhook trigger). When you click Run in the editor, Sim uses the highest-priority trigger: Start block first, then Schedule, then external triggers like webhooks. Each trigger type can also fire independently when its event occurs." },
   { question: "How do I secure my webhook endpoint?", answer: "The Generic Webhook trigger supports authentication. Enable the Require Authentication toggle, set an auth token, and optionally specify a custom header name. Incoming requests must include the token as a Bearer token in the Authorization header (or in your custom header). Requests without a valid token are rejected." },
   { question: "What happens when I test an external trigger manually?", answer: "When you click Run on a workflow with an external trigger (webhook, Slack, Gmail, etc.), Sim generates a mock payload based on the trigger's expected data structure. This lets downstream blocks resolve their variable references correctly so you can test the full workflow without waiting for a real event." },
-  { question: "Do triggers use the draft canvas or the deployed version?", answer: "All trigger-based executions (API, chat, schedule, webhook) run against the active deployment snapshot, not your draft canvas. After making changes, you need to redeploy for triggers to pick up the updated workflow version." },
+  { question: "Do triggers use the draft canvas or the deployed version?", answer: "All trigger-based runs (API, chat, schedule, webhook) use the active deployment snapshot, not your draft canvas. After making changes, you need to redeploy for triggers to pick up the updated workflow version." },
   { question: "What integrations are available as triggers?", answer: "Sim supports a wide range of trigger integrations including GitHub (push, PR, issues), Slack, Gmail, Outlook, Linear, Jira, HubSpot, Stripe, Airtable, Calendly, Typeform, Telegram, WhatsApp, Microsoft Teams, RSS feeds, and more. Each integration provides event-specific triggers like issue_created or email_received." },
   { question: "How does the Schedule trigger work?", answer: "The Schedule trigger runs your workflow on a timer using cron expressions or interval-based configuration. The schedule is managed within the schedule block settings. Like all triggers, scheduled runs execute the active deployment snapshot, so make sure to redeploy after making workflow changes." },
 ]} />

apps/docs/content/docs/en/triggers/rss.mdx

@@ -51,9 +51,9 @@ RSS triggers only fire for items published after you save the trigger. Existing
 
 <FAQ items={[
   { question: "How often is the RSS feed checked for new items?", answer: "The feed is polled every minute. On each poll, the service fetches the feed, compares items against the last checked timestamp and a list of previously seen GUIDs, and triggers your workflow only for genuinely new items." },
-  { question: "How does the poller avoid processing the same item twice?", answer: "The service tracks up to 100 recent item GUIDs and the last checked timestamp. An item is considered new only if its GUID has not been seen before and its publication date is after the last checked timestamp. Additionally, an idempotency layer prevents duplicate workflow executions for the same item." },
+  { question: "How does the poller avoid processing the same item twice?", answer: "The service tracks up to 100 recent item GUIDs and the last checked timestamp. An item is considered new only if its GUID has not been seen before and its publication date is after the last checked timestamp. Additionally, an idempotency layer prevents duplicate workflow runs for the same item." },
   { question: "Is there a limit on how many new items are processed per poll?", answer: "Yes. Each polling cycle processes a maximum of 25 new items, sorted by publication date (newest first). If a feed publishes more than 25 items between polls, only the 25 most recent are processed." },
-  { question: "What output fields are available from the RSS trigger?", answer: "Each triggered execution receives: title, link, and pubDate as top-level convenience fields, plus a full item object containing all fields (including guid, summary, content, contentSnippet, author, categories, enclosure, and isoDate), a feed object with the feed's title, link, and description, and a timestamp of when the event was processed." },
+  { question: "What output fields are available from the RSS trigger?", answer: "Each triggered run receives: title, link, and pubDate as top-level convenience fields, plus a full item object containing all fields (including guid, summary, content, contentSnippet, author, categories, enclosure, and isoDate), a feed object with the feed's title, link, and description, and a timestamp of when the event was processed." },
   { question: "What happens if the RSS feed is temporarily unreachable?", answer: "A failed fetch increments the webhook's consecutive failure counter. After 100 consecutive failures, the RSS trigger is automatically disabled. On any successful poll, the counter resets to zero." },
   { question: "Does the RSS trigger support Atom feeds?", answer: "Yes. The underlying parser (rss-parser) supports both RSS and Atom feed formats. You can use the URL of either format in the Feed URL field." },
 ]} />

apps/docs/content/docs/en/triggers/schedule.mdx

@@ -79,10 +79,10 @@ Schedule blocks cannot receive incoming connections and serve as workflow entry
 
 <FAQ items={[
   { question: "Do I need to deploy my workflow for the schedule to start?", answer: "Yes. Schedules are created in the database only when you deploy the workflow. Undeploying removes the schedule, and redeploying recreates it with the current configuration." },
-  { question: "What exactly happens after 100 consecutive failures?", answer: "After 100 consecutive failures, the schedule is automatically set to a disabled status to prevent runaway errors. A warning badge appears on the schedule block in the editor. You can click the badge to reactivate it. The failure counter resets to zero on any successful execution." },
+  { question: "What exactly happens after 100 consecutive failures?", answer: "After 100 consecutive failures, the schedule is automatically set to a disabled status to prevent runaway errors. A warning badge appears on the schedule block in the editor. You can click the badge to reactivate it. The failure counter resets to zero on any successful run." },
   { question: "Does the schedule support timezones?", answer: "Yes. The schedule configuration includes a timezone setting. Cron expressions and simple intervals are evaluated relative to the configured timezone, which defaults to UTC if not specified." },
-  { question: "What happens if my scheduled workflow is rate-limited?", answer: "If a rate limit (HTTP 429) is encountered during execution, the schedule automatically retries after a 5-minute delay rather than counting it as a failure." },
+  { question: "What happens if my scheduled workflow is rate-limited?", answer: "If a rate limit (HTTP 429) is encountered during a run, the schedule automatically retries after a 5-minute delay rather than counting it as a failure." },
   { question: "Can I have multiple schedule blocks in one workflow?", answer: "Yes. The deployment process finds all schedule blocks in the workflow and creates a separate schedule record for each one. Each schedule operates independently with its own cron expression and failure counter." },
-  { question: "What happens if the workflow is undeployed while a schedule execution is in progress?", answer: "The currently running execution will complete, but no new executions will be triggered. When the schedule next tries to fire, it checks that the workflow is still deployed and the schedule record still exists before executing." },
+  { question: "What happens if the workflow is undeployed while a scheduled run is in progress?", answer: "The currently running workflow will complete, but no new runs will be triggered. When the schedule next tries to fire, it checks that the workflow is still deployed and the schedule record still exists before running." },
 ]} />
 

apps/docs/content/docs/en/triggers/start.mdx

@@ -19,12 +19,12 @@ The Start block is the default trigger for workflows built in Sim. It collects s
 </div>
 
 <Callout type="info">
-The Start block sits in the start slot when you create a workflow. Keep it there when you want the same entry point to serve editor runs, deploy-to-API requests, and chat sessions. Swap it with Webhook or Schedule triggers when you only need event-driven execution.
+The Start block sits in the start slot when you create a workflow. Keep it there when you want the same entry point to serve editor runs, deploy-to-API requests, and chat sessions. Swap it with Webhook or Schedule triggers when you only need event-driven runs.
 </Callout>
 
 ## Fields exposed by Start
 
-The Start block emits different data depending on the execution surface:
+The Start block emits different data depending on the run surface:
 
 - **Input Format fields** — Every field you add becomes available as <code>&lt;start.fieldName&gt;</code>. For example, a `customerId` field shows up as <code>&lt;start.customerId&gt;</code> in downstream blocks and templates.
 - **Chat-only fields** — When the workflow runs from the chat side panel or a deployed chat experience, Sim also provides <code>&lt;start.input&gt;</code> (latest user message), <code>&lt;start.conversationId&gt;</code> (active session id), and <code>&lt;start.files&gt;</code> (chat attachments).
@@ -33,11 +33,11 @@ Keep Input Format fields scoped to the names you expect to reference later—tho
 
 ## Configure the Input Format
 
-Use the Input Format sub-block to define the schema that applies across execution modes:
+Use the Input Format sub-block to define the schema that applies across run modes:
 
 1. Add a field for each value you want to collect.
 2. Choose a type (`string`, `number`, `boolean`, `object`, `array`, or `files`). File fields accept uploads from chat and API callers.
-3. Provide default values when you want the manual run modal to populate test data automatically. These defaults are ignored for deployed executions.
+3. Provide default values when you want the manual run modal to populate test data automatically. These defaults are ignored for deployed runs.
 4. Reorder fields to control how they appear in the editor form.
 
 Reference structured values downstream with expressions such as <code>&lt;start.customerId&gt;</code> depending on the block you connect.
@@ -53,7 +53,7 @@ Reference structured values downstream with expressions such as <code>&lt;start.
     tools or storage steps.
   </Tab>
   <Tab>
-    Deploying to API turns the Input Format into a JSON contract for clients. Each field becomes part of the request body, and Sim coerces primitive types on ingestion. File fields expect objects that reference uploaded files; use the execution file upload endpoint before invoking the workflow.
+    Deploying to API turns the Input Format into a JSON contract for clients. Each field becomes part of the request body, and Sim coerces primitive types on ingestion. File fields expect objects that reference uploaded files; use the file upload endpoint before invoking the workflow.
 
     API callers can include additional optional properties. They are preserved
     inside <code>&lt;start.fieldName&gt;</code> outputs so you can experiment

apps/docs/content/docs/en/triggers/webhook.mdx

@@ -8,7 +8,7 @@ import { Image } from '@/components/ui/image'
 import { Video } from '@/components/ui/video'
 import { FAQ } from '@/components/ui/faq'
 
-Webhooks allow external services to trigger workflow execution by sending HTTP requests to your workflow. Sim supports two approaches for webhook-based triggers.
+Webhooks allow external services to trigger workflow runs by sending HTTP requests to your workflow. Sim supports two approaches for webhook-based triggers.
 
 ## Generic Webhook Trigger
 
@@ -30,7 +30,7 @@ The Generic Webhook block creates a flexible endpoint that can receive any paylo
 2. **Configure Payload** - Set up the expected payload structure (optional)
 3. **Get Webhook URL** - Copy the automatically generated unique endpoint
 4. **External Integration** - Configure your external service to send POST requests to this URL
-5. **Workflow Execution** - Every request to the webhook URL triggers the workflow
+5. **Workflow Run** - Every request to the webhook URL triggers the workflow
 
 ### Features
 
@@ -38,7 +38,7 @@ The Generic Webhook block creates a flexible endpoint that can receive any paylo
 - **Automatic Parsing**: Webhook data is automatically parsed and available to subsequent blocks
 - **Authentication**: Optional bearer token or custom header authentication
 - **Rate Limiting**: Built-in protection against abuse
-- **Deduplication**: Prevents duplicate executions from repeated requests
+- **Deduplication**: Prevents duplicate runs from repeated requests
 
 <Callout type="info">
 The Generic Webhook trigger fires every time the webhook URL receives a request, making it perfect for real-time integrations.
@@ -58,7 +58,7 @@ Alternatively, you can use specific service blocks (like Slack, GitHub, etc.) in
 2. **Enable Trigger Mode** - Toggle "Use as Trigger" in the block settings
 3. **Configure Service** - Set up authentication and event filters specific to that service
 4. **Webhook Registration** - The service automatically registers the webhook with the external platform
-5. **Event-Based Execution** - Workflow triggers only for specific events from that service
+5. **Event-Based Runs** - Workflow triggers only for specific events from that service
 
 ### When to Use Each Approach
 
@@ -120,7 +120,7 @@ Alternatively, you can use specific service blocks (like Slack, GitHub, etc.) in
 ### Testing Webhooks
 
 1. Use tools like Postman or curl to test your webhook endpoints
-2. Check workflow execution logs for debugging
+2. Check workflow run logs for debugging
 3. Verify payload structure matches your expectations
 4. Test authentication and error scenarios
 
@@ -153,8 +153,8 @@ Always validate and sanitize incoming webhook data before processing it in your
   { question: "What HTTP methods does the Generic Webhook endpoint accept?", answer: "The webhook endpoint handles POST requests for triggering workflows. GET requests are only used for provider-specific verification challenges (such as Microsoft Graph or WhatsApp verification). Other methods return a 405 Method Not Allowed response." },
   { question: "How do I authenticate webhook requests?", answer: "Enable the Require Authentication toggle in the webhook configuration, then set an Authentication Token. Callers can send the token as a Bearer token in the Authorization header, or you can specify a custom header name (e.g., X-Secret-Key) and the token will be matched against that header instead." },
   { question: "Can I define the expected payload structure for a webhook?", answer: "Yes. The Generic Webhook block includes an Input Format field where you can define the expected JSON schema. This is optional but helps document the expected structure. You can also use type \"file[]\" for file upload fields." },
-  { question: "Does the webhook have deduplication built in?", answer: "Yes. The webhook processing pipeline includes idempotency checks to prevent duplicate executions from repeated requests with the same payload." },
+  { question: "Does the webhook have deduplication built in?", answer: "Yes. The webhook processing pipeline includes idempotency checks to prevent duplicate runs from repeated requests with the same payload." },
   { question: "What data from the webhook request is available in my workflow?", answer: "All request data including headers, body, and query parameters is parsed and made available to subsequent blocks. Common fields like event, id, and data are automatically extracted from the payload when present." },
-  { question: "Do I need to deploy my workflow for the webhook URL to work?", answer: "Yes. The webhook endpoint checks that the associated workflow is deployed before triggering execution. If the workflow is not deployed, the webhook returns a not-found response." },
-  { question: "Does the webhook auto-disable after repeated failures?", answer: "No. Unlike polling-based triggers (RSS, Gmail, IMAP), push-based generic webhooks do not auto-disable after consecutive failures. Each incoming request is processed independently. If your workflow consistently fails, check the execution logs for error details." },
+  { question: "Do I need to deploy my workflow for the webhook URL to work?", answer: "Yes. The webhook endpoint checks that the associated workflow is deployed before triggering a run. If the workflow is not deployed, the webhook returns a not-found response." },
+  { question: "Does the webhook auto-disable after repeated failures?", answer: "No. Unlike polling-based triggers (RSS, Gmail, IMAP), push-based generic webhooks do not auto-disable after consecutive failures. Each incoming request is processed independently. If your workflow consistently fails, check the run logs for error details." },
 ]} />

apps/sim/app/api/workflows/[id]/executions/[executionId]/cancel/route.test.ts

@@ -2,6 +2,7 @@
  * @vitest-environment node
  */
 
+import { databaseMock } from '@sim/testing'
 import { NextRequest } from 'next/server'
 import { beforeEach, describe, expect, it, vi } from 'vitest'
 
@@ -203,4 +204,73 @@ describe('POST /api/workflows/[id]/executions/[executionId]/cancel', () => {
 
     expect(response.status).toBe(403)
   })
+
+  it('updates execution log status in DB when durably recorded', async () => {
+    const mockWhere = vi.fn().mockResolvedValue(undefined)
+    const mockSet = vi.fn(() => ({ where: mockWhere }))
+    databaseMock.db.update.mockReturnValueOnce({ set: mockSet })
+    mockMarkExecutionCancelled.mockResolvedValue({
+      durablyRecorded: true,
+      reason: 'recorded',
+    })
+
+    await POST(makeRequest(), makeParams())
+
+    expect(databaseMock.db.update).toHaveBeenCalled()
+    expect(mockSet).toHaveBeenCalledWith({
+      status: 'cancelled',
+      endedAt: expect.any(Date),
+    })
+  })
+
+  it('updates execution log status in DB when locally aborted', async () => {
+    const mockWhere = vi.fn().mockResolvedValue(undefined)
+    const mockSet = vi.fn(() => ({ where: mockWhere }))
+    databaseMock.db.update.mockReturnValueOnce({ set: mockSet })
+    mockMarkExecutionCancelled.mockResolvedValue({
+      durablyRecorded: false,
+      reason: 'redis_unavailable',
+    })
+    mockAbortManualExecution.mockReturnValue(true)
+
+    await POST(makeRequest(), makeParams())
+
+    expect(databaseMock.db.update).toHaveBeenCalled()
+    expect(mockSet).toHaveBeenCalledWith({
+      status: 'cancelled',
+      endedAt: expect.any(Date),
+    })
+  })
+
+  it('does not update execution log status in DB when only paused execution was cancelled', async () => {
+    mockMarkExecutionCancelled.mockResolvedValue({
+      durablyRecorded: false,
+      reason: 'redis_unavailable',
+    })
+    mockCancelPausedExecution.mockResolvedValue(true)
+
+    await POST(makeRequest(), makeParams())
+
+    expect(databaseMock.db.update).not.toHaveBeenCalled()
+  })
+
+  it('returns success even if direct DB update fails', async () => {
+    mockMarkExecutionCancelled.mockResolvedValue({
+      durablyRecorded: true,
+      reason: 'recorded',
+    })
+    databaseMock.db.update.mockReturnValueOnce({
+      set: vi.fn(() => ({
+        where: vi.fn(() => {
+          throw new Error('DB connection failed')
+        }),
+      })),
+    })
+
+    const response = await POST(makeRequest(), makeParams())
+
+    expect(response.status).toBe(200)
+    const data = await response.json()
+    expect(data.success).toBe(true)
+  })
 })

apps/sim/app/api/workflows/[id]/executions/[executionId]/cancel/route.ts

@@ -1,4 +1,7 @@
+import { db } from '@sim/db'
+import { workflowExecutionLogs } from '@sim/db/schema'
 import { createLogger } from '@sim/logger'
+import { and, eq } from 'drizzle-orm'
 import { type NextRequest, NextResponse } from 'next/server'
 import { checkHybridAuth } from '@/lib/auth/hybrid'
 import { markExecutionCancelled } from '@/lib/execution/cancellation'
@@ -83,6 +86,25 @@ export async function POST(
       })
     }
 
+    if ((cancellation.durablyRecorded || locallyAborted) && !pausedCancelled) {
+      try {
+        await db
+          .update(workflowExecutionLogs)
+          .set({ status: 'cancelled', endedAt: new Date() })
+          .where(
+            and(
+              eq(workflowExecutionLogs.executionId, executionId),
+              eq(workflowExecutionLogs.status, 'running')
+            )
+          )
+      } catch (dbError) {
+        logger.warn('Failed to update execution log status directly', {
+          executionId,
+          error: dbError,
+        })
+      }
+    }
+
     const success = cancellation.durablyRecorded || locallyAborted || pausedCancelled
 
     if (success) {

apps/sim/app/api/workflows/[id]/executions/[executionId]/stream/route.ts

@@ -48,14 +48,11 @@ export async function GET(
 
     const meta = await getExecutionMeta(executionId)
     if (!meta) {
-      return NextResponse.json({ error: 'Execution buffer not found or expired' }, { status: 404 })
+      return NextResponse.json({ error: 'Run buffer not found or expired' }, { status: 404 })
     }
 
     if (meta.workflowId && meta.workflowId !== workflowId) {
-      return NextResponse.json(
-        { error: 'Execution does not belong to this workflow' },
-        { status: 403 }
-      )
+      return NextResponse.json({ error: 'Run does not belong to this workflow' }, { status: 403 })
     }
 
     const fromParam = req.nextUrl.searchParams.get('from')

apps/sim/app/api/workflows/[id]/log/route.ts

@@ -95,7 +95,7 @@ export async function POST(request: NextRequest, { params }: { params: Promise<{
       const { traceSpans, totalDuration } = buildTraceSpans(resultWithOutput as ExecutionResult)
 
       if (result.success === false) {
-        const message = result.error || 'Workflow execution failed'
+        const message = result.error || 'Workflow run failed'
         await loggingSession.safeCompleteWithError({
           endedAt: new Date().toISOString(),
           totalDurationMs: totalDuration || result.metadata?.duration || 0,
@@ -112,7 +112,7 @@ export async function POST(request: NextRequest, { params }: { params: Promise<{
       }
 
       return createSuccessResponse({
-        message: 'Execution logs persisted successfully',
+        message: 'Run logs persisted successfully',
       })
     }
 

apps/sim/app/chat/constants.ts

@@ -6,7 +6,7 @@ export const CHAT_ERROR_MESSAGES = {
   AUTH_REQUIRED_EMAIL: 'Please provide your email to access this chat.',
   CHAT_UNAVAILABLE: 'This chat is currently unavailable. Please try again later.',
   NO_CHAT_TRIGGER:
-    'No Chat trigger configured for this workflow. Add a Chat Trigger block to enable chat execution.',
+    'No Chat trigger configured for this workflow. Add a Chat Trigger block to enable chat.',
   USAGE_LIMIT_EXCEEDED: 'Usage limit exceeded. Please upgrade your plan to continue using chat.',
 } as const
 

apps/sim/app/llms.txt/route.ts

@@ -25,10 +25,10 @@ Sim lets teams create agents visually with the workflow builder, conversationall
 
 ## Key Concepts
 
-- **Workspace**: The AI workspace — container for agents, workflows, data sources, and executions
+- **Workspace**: The AI workspace — container for agents, workflows, data sources, and runs
 - **Workflow**: Visual builder — directed graph of blocks defining agent logic
 - **Block**: Individual step such as an LLM call, tool call, HTTP request, or code execution
-- **Trigger**: Event or schedule that initiates workflow execution
+- **Trigger**: Event or schedule that initiates a workflow run
 - **Execution**: A single run of a workflow with logs and outputs
 - **Knowledge Base**: Document store used for retrieval-augmented generation
 
@@ -41,7 +41,7 @@ Sim lets teams create agents visually with the workflow builder, conversationall
 - Knowledge bases and retrieval-augmented generation
 - Table creation and management
 - Document creation and processing
-- Scheduled and webhook-triggered executions
+- Scheduled and webhook-triggered runs
 
 ## Use Cases
 

apps/sim/app/workspace/[workspaceId]/home/components/mothership-view/components/resource-content/resource-content.tsx

@@ -684,12 +684,10 @@ function EmbeddedLog({ logId }: EmbeddedLogProps) {
           </div>
         </div>
 
-        {/* Execution ID */}
+        {/* Run ID */}
         {log.executionId && (
           <div className='flex flex-col gap-1.5 rounded-md border border-[var(--border)] bg-[var(--surface-2)] px-2.5 py-2'>
-            <span className='font-medium text-[var(--text-tertiary)] text-caption'>
-              Execution ID
-            </span>
+            <span className='font-medium text-[var(--text-tertiary)] text-caption'>Run ID</span>
             <span className='truncate font-medium text-[var(--text-secondary)] text-sm'>
               {log.executionId}
             </span>

apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.ts

@@ -2967,7 +2967,7 @@ export function useChat(
         input: {},
         output: {},
         success: false,
-        error: 'Execution was cancelled',
+        error: 'Run was cancelled',
         durationMs: 0,
         startedAt: now.toISOString(),
         executionOrder: Number.MAX_SAFE_INTEGER,
@@ -2975,7 +2975,7 @@ export function useChat(
         workflowId,
         blockId: 'cancelled',
         executionId: executionId ?? undefined,
-        blockName: 'Execution Cancelled',
+        blockName: 'Run Cancelled',
         blockType: 'cancelled',
       })
 

apps/sim/app/workspace/[workspaceId]/logs/components/log-details/components/execution-snapshot/execution-snapshot.tsx

@@ -94,7 +94,7 @@ export function ExecutionSnapshot({
         >
           <div className='flex items-center gap-2 text-[var(--text-secondary)]'>
             <Loader2 className='h-[16px] w-[16px] animate-spin' />
-            <span className='text-small'>Loading execution snapshot...</span>
+            <span className='text-small'>Loading run snapshot...</span>
           </div>
         </div>
       )
@@ -108,7 +108,7 @@ export function ExecutionSnapshot({
         >
           <div className='flex items-center gap-2 text-[var(--text-error)]'>
             <AlertCircle className='h-[16px] w-[16px]' />
-            <span className='text-small'>Failed to load execution snapshot: {error.message}</span>
+            <span className='text-small'>Failed to load run snapshot: {error.message}</span>
           </div>
         </div>
       )
@@ -122,7 +122,7 @@ export function ExecutionSnapshot({
         >
           <div className='flex items-center gap-2 text-[var(--text-secondary)]'>
             <Loader2 className='h-[16px] w-[16px] animate-spin' />
-            <span className='text-small'>Loading execution snapshot...</span>
+            <span className='text-small'>Loading run snapshot...</span>
           </div>
         </div>
       )
@@ -139,8 +139,8 @@ export function ExecutionSnapshot({
             <span className='font-medium text-base'>Logged State Not Found</span>
           </div>
           <div className='max-w-md text-center text-[var(--text-secondary)] text-small'>
-            This log was migrated from the old logging system. The workflow state at execution time
-            is not available.
+            This log was migrated from the old logging system. The workflow state at the time of
+            this run is not available.
           </div>
           <div className='text-[var(--text-tertiary)] text-caption'>
             Note: {workflowState._note}
@@ -191,7 +191,7 @@ export function ExecutionSnapshot({
             >
               <DropdownMenuItem onSelect={handleCopyExecutionId}>
                 <Copy />
-                Copy Execution ID
+                Copy Run ID
               </DropdownMenuItem>
             </DropdownMenuContent>
           </DropdownMenu>,

apps/sim/app/workspace/[workspaceId]/logs/components/log-details/log-details.tsx

@@ -448,11 +448,11 @@ export const LogDetails = memo(function LogDetails({
                   </div>
                 </div>
 
-                {/* Execution ID */}
+                {/* Run ID */}
                 {log.executionId && (
                   <div className='flex flex-col gap-1.5 rounded-md border border-[var(--border)] bg-[var(--surface-2)] px-2.5 py-2'>
                     <span className='font-medium text-[var(--text-tertiary)] text-caption'>
-                      Execution ID
+                      Run ID
                     </span>
                     <span className='truncate font-medium text-[var(--text-secondary)] text-sm'>
                       {log.executionId}
@@ -576,7 +576,7 @@ export const LogDetails = memo(function LogDetails({
                       <div className='flex flex-col gap-2.5 rounded-md p-2.5'>
                         <div className='flex items-center justify-between'>
                           <span className='font-medium text-[var(--text-tertiary)] text-caption'>
-                            Base Execution:
+                            Base Run:
                           </span>
                           <span className='font-medium text-[var(--text-secondary)] text-caption'>
                             {formatCost(BASE_EXECUTION_CHARGE)}
@@ -643,8 +643,8 @@ export const LogDetails = memo(function LogDetails({
 
                     <div className='flex items-center justify-center rounded-md bg-[var(--surface-2)] p-2 text-center'>
                       <p className='font-medium text-[var(--text-subtle)] text-xs'>
-                        Total cost includes a base execution charge of{' '}
-                        {formatCost(BASE_EXECUTION_CHARGE)} plus any model and tool usage costs.
+                        Total cost includes a base run charge of {formatCost(BASE_EXECUTION_CHARGE)}{' '}
+                        plus any model and tool usage costs.
                       </p>
                     </div>
                   </div>

apps/sim/app/workspace/[workspaceId]/logs/components/log-row-context-menu/log-row-context-menu.tsx

@@ -77,14 +77,14 @@ export const LogRowContextMenu = memo(function LogRowContextMenu({
           <>
             <DropdownMenuItem onSelect={onCancelExecution}>
               <X />
-              Cancel Execution
+              Cancel Run
             </DropdownMenuItem>
             <DropdownMenuSeparator />
           </>
         )}
         <DropdownMenuItem disabled={!hasExecutionId} onSelect={onCopyExecutionId}>
           <Copy />
-          Copy Execution ID
+          Copy Run ID
         </DropdownMenuItem>
         <DropdownMenuItem disabled={!hasExecutionId} onSelect={onCopyLink}>
           <Link />

apps/sim/app/workspace/[workspaceId]/settings/components/subscription/plan-configs.ts

@@ -15,7 +15,7 @@ import type { PlanFeature } from '@/app/workspace/[workspaceId]/settings/compone
 export const PRO_PLAN_FEATURES: PlanFeature[] = [
   { icon: Zap, text: '150 runs/min (sync)' },
   { icon: Clock, text: '1,000 runs/min (async)' },
-  { icon: Timer, text: '50 min sync execution limit' },
+  { icon: Timer, text: '50 min sync run limit' },
   { icon: HardDrive, text: '50GB file storage' },
   { icon: Table2, text: '25 tables · 5,000 rows each' },
 ]
@@ -23,7 +23,7 @@ export const PRO_PLAN_FEATURES: PlanFeature[] = [
 export const MAX_PLAN_FEATURES: PlanFeature[] = [
   { icon: Zap, text: '300 runs/min (sync)' },
   { icon: Clock, text: '2,500 runs/min (async)' },
-  { icon: Timer, text: '50 min sync execution limit' },
+  { icon: Timer, text: '50 min sync run limit' },
   { icon: HardDrive, text: '500GB file storage' },
   { icon: Table2, text: '25 tables · 5,000 rows each' },
 ]

apps/sim/app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-execution-utils.ts

@@ -449,7 +449,7 @@ export function addExecutionErrorConsoleEntry(
   const isPreExecutionError = params.isPreExecutionError ?? false
   if (!isPreExecutionError && hasBlockError) return
 
-  const errorMessage = params.error || 'Execution failed'
+  const errorMessage = params.error || 'Run failed'
   const isTimeout = errorMessage.toLowerCase().includes('timed out')
   const timing = buildExecutionTiming(params.durationMs)
 
@@ -469,7 +469,7 @@ export function addExecutionErrorConsoleEntry(
       ? 'Workflow Validation'
       : isTimeout
         ? 'Timeout Error'
-        : 'Execution Error',
+        : 'Run Error',
     blockType: isPreExecutionError ? 'validation' : 'error',
   })
 }
@@ -514,7 +514,7 @@ export function addHttpErrorConsoleEntry(
     workflowId: params.workflowId,
     blockId: isValidationError ? 'validation' : 'execution-error',
     executionId: params.executionId,
-    blockName: isValidationError ? 'Workflow Validation' : 'Execution Error',
+    blockName: isValidationError ? 'Workflow Validation' : 'Run Error',
     blockType: isValidationError ? 'validation' : 'error',
   })
 }
@@ -537,7 +537,7 @@ export function addCancelledConsoleEntry(
     input: {},
     output: {},
     success: false,
-    error: 'Execution was cancelled',
+    error: 'Run was cancelled',
     durationMs: timing.durationMs,
     startedAt: timing.startedAt,
     executionOrder: Number.MAX_SAFE_INTEGER,
@@ -545,7 +545,7 @@ export function addCancelledConsoleEntry(
     workflowId: params.workflowId,
     blockId: 'cancelled',
     executionId: params.executionId,
-    blockName: 'Execution Cancelled',
+    blockName: 'Run Cancelled',
     blockType: 'cancelled',
   })
 }
@@ -652,7 +652,7 @@ export async function executeWorkflowWithFullLogging(
 
   if (!response.ok) {
     const error = await response.json()
-    const errorMessage = error.error || 'Workflow execution failed'
+    const errorMessage = error.error || 'Workflow run failed'
     addHttpErrorConsoleEntry(addConsole, {
       workflowId: wfId,
       executionId,
@@ -721,14 +721,14 @@ export async function executeWorkflowWithFullLogging(
           executionResult = {
             success: false,
             output: {},
-            error: 'Execution was cancelled',
+            error: 'Run was cancelled',
             logs: accumulatedBlockLogs,
           }
         },
 
         onExecutionError: (data) => {
           setCurrentExecutionId(wfId, null)
-          const errorMessage = data.error || 'Execution failed'
+          const errorMessage = data.error || 'Run failed'
           executionResult = {
             success: false,
             output: {},

apps/sim/components/emails/notifications/workflow-notification-email.tsx

@@ -70,7 +70,7 @@ export function WorkflowNotificationEmail({
   const message = alertReason
     ? 'An alert was triggered for your workflow.'
     : isError
-      ? 'Your workflow execution failed.'
+      ? 'Your workflow run failed.'
       : 'Your workflow completed successfully.'
 
   return (
@@ -102,7 +102,7 @@ export function WorkflowNotificationEmail({
       </Section>
 
       <Link href={logUrl} style={{ textDecoration: 'none' }}>
-        <Text style={baseStyles.button}>View Execution Log</Text>
+        <Text style={baseStyles.button}>View Run Log</Text>
       </Link>
 
       {rateLimits && (rateLimits.sync || rateLimits.async) ? (

apps/sim/hooks/queries/logs.ts

@@ -292,9 +292,9 @@ export function useCancelExecution() {
       const res = await fetch(`/api/workflows/${workflowId}/executions/${executionId}/cancel`, {
         method: 'POST',
       })
-      if (!res.ok) throw new Error('Failed to cancel execution')
+      if (!res.ok) throw new Error('Failed to cancel run')
       const data = await res.json()
-      if (!data.success) throw new Error('Failed to cancel execution')
+      if (!data.success) throw new Error('Failed to cancel run')
       return data
     },
     onMutate: async ({ executionId }) => {

apps/sim/lib/logs/execution/logging-session.ts

@@ -555,7 +555,7 @@ export class LoggingSession {
               models: {},
             }
 
-      const message = error?.message || 'Execution failed before starting blocks'
+      const message = error?.message || 'Run failed before starting blocks'
 
       const errorSpan: TraceSpan = {
         id: 'workflow-error-root',
@@ -994,7 +994,7 @@ export class LoggingSession {
         traceSpans: params?.traceSpans,
         endedAt: params?.endedAt,
         totalDurationMs: params?.totalDurationMs,
-        errorMessage: 'Execution was cancelled',
+        errorMessage: 'Run was cancelled',
         isError: false,
         finalizationPath: 'cancelled',
         finalOutput: { cancelled: true },
@@ -1021,7 +1021,7 @@ export class LoggingSession {
         traceSpans: params?.traceSpans,
         endedAt: params?.endedAt,
         totalDurationMs: params?.totalDurationMs,
-        errorMessage: 'Execution paused but failed to store full trace spans',
+        errorMessage: 'Run paused but failed to store full trace spans',
         isError: false,
         finalizationPath: 'paused',
         finalOutput: { paused: true },
@@ -1041,7 +1041,7 @@ export class LoggingSession {
     requestId?: string
   ): Promise<void> {
     try {
-      const message = errorMessage || 'Execution failed'
+      const message = errorMessage || 'Run failed'
       await db
         .update(workflowExecutionLogs)
         .set({

apps/sim/lib/logs/search-suggestions.ts

@@ -57,25 +57,25 @@ export const FILTER_DEFINITIONS: FilterDefinition[] = [
   {
     key: 'cost',
     label: 'Cost',
-    description: 'Filter by execution cost',
+    description: 'Filter by run cost',
     options: [
       {
         value: '>0.01',
         label: 'Over 2 credits',
-        description: 'Executions costing more than 2 credits',
+        description: 'Runs costing more than 2 credits',
       },
       {
         value: '<0.005',
         label: 'Under 1 credit',
-        description: 'Executions costing less than 1 credit',
+        description: 'Runs costing less than 1 credit',
       },
       {
         value: '>0.05',
         label: 'Over 10 credits',
-        description: 'Executions costing more than 10 credits',
+        description: 'Runs costing more than 10 credits',
       },
-      { value: '=0', label: 'Free', description: 'Free executions' },
-      { value: '>0', label: 'Paid', description: 'Executions with cost' },
+      { value: '=0', label: 'Free', description: 'Free runs' },
+      { value: '>0', label: 'Paid', description: 'Runs with cost' },
     ],
   },
   {
@@ -104,13 +104,13 @@ export const FILTER_DEFINITIONS: FilterDefinition[] = [
   {
     key: 'duration',
     label: 'Duration',
-    description: 'Filter by execution duration',
+    description: 'Filter by run duration',
     options: [
-      { value: '>5s', label: 'Over 5s', description: 'Executions longer than 5 seconds' },
-      { value: '<1s', label: 'Under 1s', description: 'Executions shorter than 1 second' },
-      { value: '>10s', label: 'Over 10s', description: 'Executions longer than 10 seconds' },
-      { value: '>30s', label: 'Over 30s', description: 'Executions longer than 30 seconds' },
-      { value: '<500ms', label: 'Under 0.5s', description: 'Very fast executions' },
+      { value: '>5s', label: 'Over 5s', description: 'Runs longer than 5 seconds' },
+      { value: '<1s', label: 'Under 1s', description: 'Runs shorter than 1 second' },
+      { value: '>10s', label: 'Over 10s', description: 'Runs longer than 10 seconds' },
+      { value: '>30s', label: 'Over 30s', description: 'Runs longer than 30 seconds' },
+      { value: '<500ms', label: 'Under 0.5s', description: 'Very fast runs' },
     ],
   },
 ]
@@ -225,8 +225,8 @@ export class SearchSuggestions {
     suggestions.push({
       id: 'filter-key-executionId',
       value: 'executionId:',
-      label: 'Execution ID',
-      description: 'Filter by execution ID',
+      label: 'Run ID',
+      description: 'Filter by run ID',
       category: 'filters',
     })
 
@@ -283,7 +283,7 @@ export class SearchSuggestions {
           id: `filter-value-trigger-${t.value}`,
           value: `trigger:${t.value}`,
           label: t.label,
-          description: `${t.label}-triggered executions`,
+          description: `${t.label}-triggered runs`,
           category: 'trigger' as const,
           color: t.color,
         }))
@@ -604,7 +604,7 @@ export class SearchSuggestions {
         id: `trigger-match-${trigger.value}`,
         value: `trigger:${trigger.value}`,
         label: trigger.label,
-        description: `${trigger.label}-triggered executions`,
+        description: `${trigger.label}-triggered runs`,
         category: 'trigger' as const,
         color: trigger.color,
       }))