Schedule Integration
The Cron trigger runs a workflow automatically on a schedule you define. You can pick a frequency such as every few minutes, hourly, daily, weekly, or monthly, and set the exact hour and minute it should fire. Schedules run in the timezone you select, and a single trigger can hold multiple schedule entries so one workflow can run at several different times. It is the right starting point for any recurring job that should happen on its own without anyone clicking Run.
What you can automate with Schedule
Pick one to start building it.
Schedule Operations
Templates using Schedule
Stripe Revenue Digest Agent
Turns yesterday's Stripe activity into one Slack message every morning: what came in, what failed, who churned, and the one thing worth checking today. Revenue questions usually get answered by whoever is willing to open the Stripe dashboard and squint at it. This agent reads yesterday's charges, invoices, and subscriptions every morning and posts one Slack message with the real figures, each currency kept separate and nothing projected. Finance and founder teams use it so failed payments and cancellations get noticed the next day instead of at month end. ## What people use it for - **Catch a failure spike same day** - A card network problem or a broken billing update shows up as an unusual failure count the next morning, while those customers are still recoverable. - **Churn you hear about immediately** - Every cancelled subscription is named with the customer and the amount, so the save conversation happens this week rather than at the quarterly review. - **Numbers finance can trust** - Each figure is copied from a Stripe response in Stripe's own currency, with no conversions, no rounding, and no projections layered on top of it. - **One money picture for everyone** - A short message in a shared channel means support and sales see the same revenue picture as the founder, without anyone else needing Stripe access. ## Before you fork **What do I need connected before this runs?** A Stripe account with read access to charges, invoices, subscriptions, and balance transactions, plus a Slack workspace and the channel you want the digest in. No write permissions are used. The first Test Run builds a full digest from a staged morning so you can settle the format before it goes live. **Will it touch my billing?** No. It reads four Stripe list endpoints and writes one Slack message. Its instructions say never to retry, refund, or cancel anything and never to contact a customer, and no Stripe write operation is wired into the template. Every recovery action stays a human decision. **We bill in several currencies. Does that work?** Yes, and it deliberately never merges them. Each currency gets its own line with Stripe's own figure, because a combined total depends on which rate you picked and on which day. If you want one number, do the conversion downstream where the rate is your choice to defend.
Weekly Changelog Agent
Turns the week's merged pull requests into one readable Friday changelog in Slack, authors credited, pull requests linked, and nothing invented about what a change does. Changelogs get written the week somebody has time, which is never the week things shipped. Every Friday afternoon this agent reads the pull requests merged since Monday and writes the week in plain language: what shipped, what got fixed, what breaks, and who did it. It holds up because it describes each change from the pull request itself and lists anything it cannot describe rather than filling the gap with a guess. ## What people use it for - **Tell support what shipped** - Support finds out about a change from a confused customer more often than from engineering. One Friday message in plain language means they read it before Monday's tickets arrive. - **Surface undocumented breaking changes** - Anything that removes or renames something lands in BREAKING with the migration note quoted, or with a line saying the author never wrote one. That question gets asked while the author is still around. - **Stop writing release notes by hand** - The raw material is already in your pull request titles and bodies. This turns that into a written changelog every week without anyone opening the compare view on a Friday evening. - **Give the company a Friday read** - Non engineers get one message they can actually follow, with authors credited by handle. It is the cheapest way to make a quiet infrastructure week visible to the people funding it. ## Before you fork **What does it need connected?** A GitHub credential with read access to the repositories you want covered, and one Slack channel to post in. During setup you name the repos, the audience, and the style you want. It only reads from GitHub and never comments, tags, publishes a release, or pushes anything. **What does it cost to run?** One run a week per workflow, whether your team merged four pull requests or forty. The run reads the week's merges and posts a single message, so cost tracks the schedule rather than your repo size. Teams that ship daily sometimes move it to twice a week, which doubles it. **What if it describes a change wrongly?** It writes only from the pull request title, body and linked issue, so a wrong line usually means a pull request described itself badly, which is worth knowing. A merge with no usable description goes into INTERNAL marked description unclear instead of being narrated. You can rehearse it on the staged weeks before pointing it at your real repos.
Outlook Daily Calendar Brief
Reads today's Outlook calendar at 7am and posts one Slack brief: internal meetings on a line each, every outside meeting carrying the company, open deals and last contact from HubSpot, and the parts of the day that still need moving. In a Microsoft shop the calendar is the org chart, and it is also where a customer meeting hides behind a distribution list and a room booking. This agent reads today's Outlook calendar at 7am, separates the outside meetings from the internal ones, and puts what HubSpot knows about each external attendee under their meeting: the company, the deals in play, the last time anybody spoke to them. It then names the parts of the day that will hurt: the runs with no gap, the meeting nobody has accepted, the call where only optional colleagues were invited. ## What people use it for - **Ready before the commute** - The whole day arrives at 7am on a phone with outside meetings already separated from internal ones. Nothing to open on the train, nothing to cross reference before the first call connects. - **Distribution lists unpacked** - An invite reading all EMEA or hiring panel tells you nothing about who is coming. The brief opens the event and reports the actual people, while never mistaking a room or a mailbox for an attendee. - **The day's pressure named early** - Back to back runs, a customer call nobody has accepted, and two things booked in the same hour all surface while there is still time to move one of them. - **Works from a delegated calendar** - Assistants who run somebody else's diary connect the mailbox they manage, and the brief lands wherever that pair actually talks. Same output, different chair. ## Before you fork **Can it read a shared or delegated mailbox?** Yes, provided the Microsoft account you connect already has access to that calendar, which is how most assistants work anyway. A single workflow covers a single calendar, so a team of five ends up with five copies, each posting into whichever channel or direct message suits that person. **Our channel is not private. What about sensitive meetings?** An event marked private is reduced to its time and its length, with subject, body and attendees left out completely. Everything else is what a colleague would see by opening the invite, plus CRM records anyone with HubSpot access can already read. If a meeting should not appear at all, mark it private in Outlook and the brief respects that. **What does it need from HubSpot, and what does a run cost?** Read access to contacts and deals and nothing beyond it: the CRM is never written to, and no attendee is ever mailed or messaged. A run is one calendar read, a lookup for each external attendee, and one message, so a day holding two customer meetings costs a fraction of a day holding eight.
Jira Sprint Status Digest
Posts the standup instead of holding it: yesterday's closes, today's work in progress, each blocked ticket with its hold quoted from the issue, plus every item that arrived in the sprint or vanished from it overnight. Standup is twelve people taking turns to read out a board that everybody could have read. Each morning this agent runs your sprint JQL and posts one Slack message: yesterday's closes, the work in flight, every blocked issue with the reason quoted from the ticket itself, and whatever entered or left the sprint since it opened. Teams spread across time zones get the same picture without needing to be awake at the same moment as each other. ## What people use it for - **Standup becomes something you read** - The circle exists because nobody has looked at the board. Once the board turns up in Slack at nine, the meeting either shrinks or quietly stops, and the people in the wrong time zone stop missing it entirely. - **Blockers arrive with their reason** - Each blocked line quotes the impediment text and how long it has sat there, so a four day wait on an outside vendor reads as four days rather than as a red icon nobody has clicked. - **Mid sprint additions stop hiding** - Work that turned up after the sprint opened is listed by key, so at the end of the week nobody has to argue about whether scope changed, only about what to do next time. - **A written record for retro** - Each morning's message stays in the channel, so at retro you scroll back to the day a blocker first appeared rather than reconstructing the fortnight from memory. ## Before you fork **We already have a board and sprint reports. Why a digest?** Both wait for somebody to open them, and neither one quotes the blocker text out loud. This lands where your team is already typing, with the flag reasons and the late arrivals spelled out. If your board honestly does get read by everyone before standup, you do not need this. **Can it change anything on the board?** No. Its Jira access is a search and a read, and it is instructed never to transition an issue, post a comment, or edit the sprint. The Slack message is the entire output, so the worst outcome is a wrong line in a channel rather than a wrong state on a board twelve people are working from. **What does it need from Jira, and what does a month of mornings cost?** A Jira credential that can browse the project and run JQL, plus a Slack channel to post into. It runs once each morning whether the sprint holds nine issues or ninety, so spend follows the schedule rather than the board. The schedule step sets the time and the time zone, which lets it land twenty minutes ahead of standup wherever your team sits.
Daily Calendar Brief Agent
Sends one Slack brief at 7am with the day laid out: internal meetings compressed to a line each, every customer meeting carrying its company, open deals and last touch from HubSpot, and the attendees no record covers. Most people meet their day at 08:59 and discover on the call that the person opposite is halfway through a renewal. This agent reads the whole calendar at 7am, separates customer meetings from internal ones, and pulls each outside attendee's company, deals, and last contact out of HubSpot into a single Slack brief. It also lists what the CRM does not know, which tends to be the part worth fixing before the first meeting starts. ## What people use it for - **The whole day at 7am** - One message replaces opening six invites and guessing who the attendees are. Before the first call the owner already knows which two meetings need thinking about. - **Never walk into a renewal cold** - A customer meeting arrives with the open deal, its stage and value, and the date somebody last spoke to them sitting directly underneath the time. - **Internal meetings compressed** - Standups, one to ones, and reviews take a single line each. The customer half of the day stays readable rather than drowning in recurring invites. - **A daily list of CRM holes** - Attendees with no record and accounts nobody has touched appear every morning as a short list. Teams tend to repair more of their CRM this way than in any cleanup project. ## Before you fork **Whose calendar does it read?** The calendar belonging to the Google account you connect, which for most people is their own work calendar. If your customer meetings live on a shared team calendar, connect that one instead. A workflow covers a single calendar, so four reps end up with four copies, each posting wherever suits them. **Can I move it off 7am?** Yes, the hour and the days sit on the schedule trigger in the canvas, and it is worth restricting it to weekdays unless you enjoy a Sunday brief listing nothing. Teams spread across regions usually fork it once per region rather than sending everyone one brief at an hour that suits nobody. **Will it touch my calendar or contact anybody?** No. The calendar tools wired in only read events and the HubSpot tools only search and read. It never accepts, declines, or moves a meeting, never mails an attendee, and writes nothing back to the CRM. The cost is one run each morning plus the lookups that day's outside attendees need.
Linear Cycle Progress Digest
Answers the cycle question worth asking on day four rather than day fourteen: is this cycle keeping pace with the last one, what has stopped moving, and what got added after it opened. You can tell a cycle went badly on its last day, which is the one day nothing can be done about it. Every morning this agent reads the running cycle against the two before it and posts the numbers that show whether the team is roughly where it usually is by now, together with the work that has gone quiet and the issues that landed after the cycle opened. It is a health read rather than a task list, and it names the issues so the conversation has somewhere to begin. ## What people use it for - **See the slip on day four** - Holding today next to the same day of the last cycle turns a vague feeling that things are dragging into a number, with a week and a half still left to do something about it. - **Find the work that went quiet** - Anything in progress past your threshold is listed with its age and its owner. Long lived in progress issues are where cycles leak, and they hide on a board because they look exactly like work happening. - **Make late arrivals countable** - Nine issues landing on a Thursday after a customer escalation is worth having in writing when the cycle closes short. The agent lists them and adds no editorial of its own. - **Works on teams that never point** - Plenty of Linear teams leave every estimate empty. The digest counts issues and labels the figures as counts, rather than presenting a number that quietly mixes estimated work with unestimated work. ## Before you fork **We do not use estimates. Is this any use to us?** Yes, and it expects that. With estimates empty it counts issues and says on the line that these are counts, so nothing silently blends pointed work with unpointed work. Teams that do estimate get the same headings computed from their own estimate field instead. **How is this different from Linear's own cycle graph?** The graph shows the shape once you open it and remember to. This arrives in the channel your team already lives in, names the specific issues that produced the shape, and holds the previous cycle up beside the current one so a slow opening week is legible on day four. Run both, they answer different questions. **What can it change in Linear, and what do the runs add up to?** Nothing at all. Its Linear access is read only: no edits, no comments, no cycle changes, so a mistake shows up as an odd line in Slack and never as a moved issue. One run each morning per team you point it at, whether the cycle holds twenty issues or two hundred, so what you pay tracks the number of mornings and nothing besides.
Frequently asked questions
Ready to build with Schedule?
Start building workflows in minutes with our visual builder. No code required.