Deciding whether a workflow should run on a clock or react to an event
10-minute decision
For each job, name in one sentence what a day of delay would cost
Start with one question: what does waiting cost?
The whole decision usually collapses to a single question: if this job ran a few hours later than it could, what would that cost? When the answer is “nothing much,” put the work on a schedule—a fixed clock that runs whether or not anything happened. When the answer is “the outcome changes,” use an event trigger—the work starts the moment a specific thing occurs.
Answer that question per job, not per business. The same founder can want a Friday pipeline summary, where waiting is fine, and an instant reply to a hot enquiry, where waiting loses the sale. The common mistake is deciding by which option sounds more advanced: an event trigger is not a smarter schedule, it is a different tool for a different need.
How to judge it: if you can name the cost of a day’s delay in one sentence and it makes you wince, you want an event trigger; if you can’t, a schedule is simpler, calmer, and cheaper to run.
Use a schedule for predictable, repeatable work
Schedules fit work that is valuable at a regular beat: a weekly summary, a daily inbox triage, a monthly report, routine housekeeping. You choose the cadence—every morning, every Monday—and the agent runs on that clock, in a time zone you set, whether or not there is anything new to find.
The advantages are calm ones. A schedule is easy to anticipate, easy to budget, and easy to test: run it once, read the output, and you have seen what every future run will look like. Nothing fires unexpectedly at 2 a.m.
How to judge it: the output should arrive complete and on time, and no one downstream should be waiting on it between runs. If people keep asking for the report before the scheduled run lands, the cadence is too slow for the job.
The failure case is putting time-sensitive work on a slow clock. A refund request that arrives at 9:05 a.m. and waits for tomorrow’s 9 a.m. run is a schedule doing quiet damage. The trade-off is latency for predictability: a schedule may run when there is nothing to do—a harmless, low-cost miss—but it will also make urgent work wait its turn.
Use case: a studio’s enquiry follow-up
Tomas runs a one-person web-design studio. Two jobs sit on his list: a Friday summary of where each project stands, and a first reply to enquiries that arrive through his site’s contact form. To keep setup simple, he put both on the same 9 a.m. schedule. It held until a Friday-evening enquiry sat unanswered until Monday—by then the prospect had hired someone who replied that same night.
He weighed three options. Move everything to instant event triggers: fast, but the weekly summary gains nothing and the drafts could fire in duplicate. Keep everything on a schedule but run it hourly: still up to an hour late, and burning runs overnight for nothing. Or split the two jobs by what waiting costs each one.
He split them. The weekly summary stays on a Friday schedule, because a day’s delay costs nothing. The enquiry reply moves to an event trigger on “contact form submitted,” so a draft is ready within a minute—though sending still waits behind his approval, because a message goes out under his name. As a safety net he keeps a once-daily schedule that sweeps for any enquiry the trigger missed, with a duplicate check on the enquiry’s email so a late-caught lead is never drafted twice.
The lesson: he didn’t need one trigger type for the whole business. He needed to ask, job by job, what a delay would cost—and let that answer pick the tool.
Tomas’s jobs, matched to what waiting costs
Illustrative choices from Tomas’s studio—an example of matching each job to the cost of a delay, not a customer result.
A day’s delay costs nothing, so a Friday schedule is enough.
Drafted within a minute of the form—sending still waits for approval.
A daily sweep catches anything the trigger dropped; a duplicate check stops a second draft.
Use an event trigger for time-sensitive change
An event trigger starts the work when a defined thing happens: a form is submitted, a deal moves to “Negotiation,” a document lands in a folder, a payment fails. Instead of asking “is it time yet?” on a clock, it waits for the one signal you named and reacts—often within seconds.
This is the right tool when the value lives in the moment: a reply while the prospect is still on your site, a flag before the order ships, a nudge while the customer is still annoyed enough to answer. It also runs only when there is real work, so a good event trigger can be quieter than a frequent schedule.
How to judge it: it should fire on the events you meant and stay silent otherwise. Count how often it runs and reaches “no action needed”—if most triggers end there, the event is defined too broadly.
Two failure cases are common. The first is subscribing to too much—“any inbox change” instead of “enquiry-form submitted”—which buries the useful runs in noise and cost. The second is the duplicate: many event systems deliver the same signal more than once, so without a guard the agent drafts the same reply twice. The trade-off is speed for control—events react fast but demand a narrow definition, duplicate protection, and sample events to test against.
Put the two side by side
When a job could plausibly go either way, compare the options against the things that actually differ. The skill is matching the tool to the need, not picking a favorite and forcing every job into it.
| What the job needs | Schedule | Event trigger |
|---|---|---|
| Predictable timing | Strong | Variable |
| Fast reaction | Limited | Strong |
| Easy to test | Run it once | Needs sample events |
| Volume control | Simple | Needs limits |
| Quiet when idle | Runs anyway | Only on a signal |
Read the table as a tie-breaker, not a scoreboard. Most jobs are strong in one column and weak in the other, and that lopsidedness is the answer: a job marked “Strong” on fast reaction and “Variable” on predictable timing is telling you to use an event trigger.
Run both when a record is too important to miss
Sometimes one job deserves both. Use the event trigger for speed and add a slower schedule as a safety net: a once-a-day run that sweeps for anything the trigger should have caught but didn’t—because a signal was missed, an integration dropped, or the agent was mid-run. Important records—paying leads, refunds, contract deadlines—are where this belt-and-suspenders pattern earns its cost.
The catch is doing the work twice. If the event trigger already drafted a reply and the nightly sweep finds the same lead and drafts another, the customer gets two messages. Both paths must recognize the same record by a stable identifier and check “already handled?” before acting, so the second path sees the first path’s work and stops.
How to judge it: over a week the safety net should catch a handful of genuine misses and duplicate nothing. If it never catches anything, drop it; if it keeps re-doing handled work, the duplicate check isn’t keyed on the right identifier. The trade-off is reliability for a little more complexity and spend—worth it for records you can’t afford to miss, wasteful for a newsletter draft.
Try this next
- List each recurring job and write, in one sentence, what a day of delay would cost it.
- Put the “costs little” jobs on a schedule with a set cadence and time zone; put the “outcome changes” jobs on a narrowly defined event trigger.
- For any record important enough to run both ways, add a daily safety-net schedule plus a duplicate check keyed on a stable identifier.
- Keep anything that sends, pays, publishes, or deletes behind an approval step—whichever trigger starts it.
Sources and further reading
These primary references support the article’s split between scheduled and event-driven work, the controls an event trigger needs, and the duplicate protection required when you run both.
Reference for recurring schedules: mapping a cadence to a job, running in UTC, and testing a run before you rely on it.
GitHub DocsBest practices for using webhooksWhy event subscriptions should stay minimal and verified, and why an event may be redelivered—the narrow-definition discipline an event trigger needs.
Stripe DocsReceive Stripe events in your webhook endpointDocuments that an endpoint can receive the same event more than once and recommends logging processed IDs so you never act twice—the basis for duplicate protection when both paths run.
Ready to put one useful workflow to work?
Start with one clear job, a result you can review, and boundaries you understand.
See launch pricing