TrigRun
Getting Started

What is TrigRun

Schedule HTTP requests to any public URL with cron expressions, recurring intervals, or one-time triggers.

TrigRun is a cron-as-a-service platform. You give it a URL and a schedule, and it makes HTTP requests to that URL on time, every time.

What you can do

  • Schedule any public URL — GET, POST, PUT, PATCH, or DELETE to any HTTP/HTTPS endpoint reachable from the public internet.
  • Use any schedule type — Cron expressions (0 2 * * *), recurring intervals (every N minutes), one-time future timestamps, immediate one-shot triggers, workflow jobs, or inbound webhook-triggered jobs.
  • Run step-driven workflows — Chain HTTP steps, pass data between steps, pause for webhook callbacks, and wait for approval before continuing.
  • Monitor existing systems — Create heartbeat monitors with unique ping URLs and alert when expected check-ins stop arriving.
  • Inspect every execution — See status codes, latency, response previews, and error details for every attempt.
  • Retry on failure — Configurable retry policies with exponential backoff. Choose which status codes trigger retries.
  • Get notified — Attach webhook, email, Slack, Discord, or Telegram notifications to job events (success, failure, completion).
  • Store secrets safely — Encrypted secrets that you reference in job headers with {{secret.name}} syntax. Values are never returned by the API.
  • Recover failed runs — Replay executions, inspect parked waiting states, and manage dead-lettered failures.
  • Automate everything — REST API, CLI (trigrun), crontab import, MCP server for AI agents, llms.txt / llms-full.txt for LLM consumption, and OpenAPI spec for code generation.

Core concepts

Workspace — Your billing and data isolation boundary. All jobs, secrets, and team members belong to a workspace.

Job — A saved HTTP request definition with a schedule. Jobs have a name, target URL, HTTP method, optional headers/body, schedule configuration, and retry policy. Workflow jobs are the step-driven variant: they chain HTTP calls and can pause for webhook callbacks or approval steps. Inbound webhook-triggered jobs use the same workflow engine, but they start from a public secret URL instead of a schedule.

Execution — One logical run of a job. Each execution tracks its scheduled time, current status, and the outcome of delivery attempts.

Attempt — One HTTP delivery attempt within an execution. TrigRun records the status code, latency, response headers, and a truncated body preview for every attempt.

Secret — An encrypted value stored in your workspace. Reference secrets in job headers using {{secret.name}} syntax — TrigRun resolves them at execution time.

Notification channel — A destination for alerts: webhook URL, email address, Slack webhook, or Discord webhook. Attach channels to jobs with rules that fire on success, failure, or completion.

Monitor — A heartbeat check with a unique ping_url. Your own process calls it periodically. If TrigRun stops receiving pings on time, the monitor transitions to down and can notify your team.

How it works

You create a job
    ↓
TrigRun schedules it
    ↓
At the scheduled time, TrigRun makes the HTTP request
    ↓
If it fails, TrigRun retries with exponential backoff
    ↓
You see the result in the dashboard, API, or CLI
    ↓
Notifications fire based on your rules

Interfaces

InterfaceBest for
Web dashboardVisual job management, execution inspection
REST APIProgrammatic integration, CI/CD pipelines
CLI (trigrun)Terminal workflows, scripting, automation
MCP serverAI agents managing request-based jobs, executions, secrets, and notifications
OpenAPI specSDK generation, API exploration tools
llms.txt / llms-full.txtLLM context loading for AI-assisted development

If you want to work from the terminal, start with the CLI Overview.

What TrigRun does not do

  • Execute arbitrary code — it only makes HTTP requests to URLs you provide.
  • Reach private networks — targets must be publicly accessible.
  • Guarantee exactly-once delivery — the guarantee is at-least-once.

On this page