When Flows Run

Schedules give flows a heartbeat — events give them reflexes

Flows are powerful on their own, but they really come alive when they run themselves.

There are two ways that happens: schedules and events. Schedules are the heartbeat — steady, predictable, “check this every morning.” Events are the reflexes — instant reactions to things happening in the outside world.

Both use a single trigger line at the top of your flow. That’s it — one line turns a manual flow into an automated one.

Schedules

Add an every line before your first step:

every hour
/github fetch open issues
summarize blockers

This flow checks GitHub every hour and summarizes what’s blocking your team. No cron syntax, no configuration UI — just plain English.

Picking a frequency

How do you pick? Think about how stale the data can get before it matters:

• 5–15 minutes — monitoring and alerting. Uptime checks, error rate spikes, deployment health. You want to know fast.
• 30 minutes to hourly — dashboards and digests. Open PRs, support tickets, queue depth. Frequent enough to stay current, not so frequent it’s noisy.
• Daily — morning briefings and end-of-day summaries. The “what happened today” flows. Pair with a specific time so your team gets them when they’re actually looking.
• Weekly — retrospectives, metrics rollups, sprint summaries. Friday afternoon is popular.
• Monthly — billing reconciliation, monthly reports, big-picture trends.

Daily flows

Specify a time in 24-hour format after day:

every day 09:00
/linear fetch issues updated yesterday
summarize
/notify alert @team

every day 18:00
/github fetch PRs merged today
format as changelog
/notify alert @engineering

If no time is given, daily flows run at midnight.

Weekly flows

Specify a day name (monday through sunday) and an optional time. The week keyword is optional — every monday is equivalent to every week monday:

every week friday 17:00
/stripe payments this week
calculate totals
/notify alert @finance

every monday 09:00
/linear fetch issues assigned to me
prioritize for the week

Monthly flows

Monthly flows run on the 1st of each month:

every month
/stripe payments last month
/one-dollar-stats monthly
summarize revenue and traffic
/notify alert @leadership

Events

This is where things get really interesting.

Your Stripe webhook fires, and within seconds your team knows about the big payment. A Sentry alert triggers, and the on-call engineer gets a formatted summary before they even open their laptop. Someone pushes to main, and your deploy channel lights up.

Event triggers make your flows react to the world in real time.

How it works

Use on app.event to react to a specific event:

on stripe.payment
check if amount > 1000
/notify alert @finance about large payment

Or on app to catch everything from that app:

on stripe
/chat message in parent channel

The syntax is on <appId>, on <appId>.*, or on <appId>.<eventName>. When the specified app emits a matching event, the flow runs with the event payload as the first step’s input.

Auto-registered webhooks

This is one of those things that sounds small but changes everything.

When you write on stripe.payment, start.chat automatically registers the webhook with Stripe for you. You don’t copy a URL, you don’t paste it into a dashboard, you don’t configure secrets or verify signatures. Write the trigger line, and the platform handles registration, verification, and retries behind the scenes.

Delete the flow? The webhook gets cleaned up automatically too.

Accessing event data

Use {{event}} to reference the full event payload in subsequent steps, or {{event.field}} to access a specific field:

on stripe.payment
if {{event.amount}} > 10000
  /notify alert @finance about large payment of {{event.amount}}

on github.push
if {{event.branch}} == "main"
  /notify alert @team about push to main by {{event.author}}

The event payload is JSON — nested fields work too: {{event.customer.email}}.

Webhook status

The flow UI shows webhook status next to each event trigger:

• listening — webhook is active and receiving events
• error — the external service reported a delivery problem
• inactive — webhook was paused or the app was disconnected

Available events

Events are defined by each installed app. Here are the events available from built-in apps:

Real-world examples

Your CI breaks — the on-call knows immediately:

on github.ci
if the workflow failed
/notify alert @oncall about CI failure

A Sentry alert fires — engineering gets a clean summary, not a raw dump:

on sentry.alert
format the error details
/notify alert @engineering

A customer churns — the success team can reach out before it’s too late:

on stripe.subscription
if the subscription was cancelled
/notify alert @success about churned customer

A deploy fails — devops knows before anyone files a ticket:

on vercel.deployment
if the deploy failed
/notify alert @devops about failed deployment

Someone mentions a deploy in chat — route it to the right team:

on chat.message
if the message mentions a deploy
/notify alert @devops about deploy mention

A generic webhook comes in — parse it and notify:

on webhook.receive
extract the relevant data
/notify alert @team

Managing triggers

Open a flow’s detail pane to configure its trigger. Select manual, schedule, or event, then set the frequency and time. Switch to manual to pause automatic runs without deleting the flow.

Each flow can only have one trigger type. To have both scheduled and event-driven behavior, create separate flows.

Run history

Every run is preserved in the flow’s thread with its start time, status, output, and any errors. This helps debug scheduling issues and track performance over time.