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.
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.
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.
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.
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.
Snowflake Metrics Digest
Wakes the warehouse once a morning, runs only the statements on your list, and posts one Slack digest with the change since yesterday and any statement that failed quoted verbatim. Somebody on your team resumes the warehouse most mornings to look at the same three numbers, and every one of those check ins spends credits. This agent does that run once, at 08:00: your statements in order, results collected as each one finishes, then a single Slack digest with the change since yesterday and any statement that failed quoted in Snowflake's own words. It submits nothing outside your list and never retries, so the warehouse wakes up once a day for a cost you can predict. ## What people use it for - **One warehouse wake up a day** - Rather than five people resuming a warehouse at five different times for five different numbers, the list runs once and everyone reads the same message. The credits go into a single window you can size. - **Metrics without a BI seat** - Finance, support and founders read the digest in Slack. Nobody needs a Snowflake login, a role grant, or a reporting licence to see how yesterday went. - **A failed statement is news** - When a view gets replaced or a grant is revoked, the digest names the statement and quotes the error the same morning. A silent hole in a dashboard can go unnoticed for weeks. - **Rows stay in the warehouse** - Aggregates land in Slack and raw result rows do not, so what you put in the statement list is exactly what a channel can ever see. That matters when the tables underneath hold customer or patient records. ## Before you fork **Which role and warehouse should I point it at?** Make a dedicated role with SELECT on just the views your statements read and USAGE on a small warehouse, an extra small one with a short auto suspend is plenty. Connect that role, add the Slack channel, and write your statements out with the database and schema fully qualified, because the agent never issues a USE DATABASE to fill in a gap. **How many credits will this burn?** An extra small warehouse costs one credit per hour, so a two minute morning run is roughly a thirtieth of a credit and a full month of digests lands near one credit, plus whatever your heaviest statement makes the warehouse work for. It never retries, so a broken statement costs a single attempt. Keeping the list to statements that return in seconds is what keeps that number small. **Could customer data end up in a Slack channel?** Only if your statements return it. The agent is told to post the aggregates the digest style asks for and never to paste raw result rows, so a statement that counts orders puts a count in Slack. A statement that selects a hundred customer rows is a hundred customer rows sitting in a channel, which is a reason to write aggregates into the list rather than to rely on the instruction. Masking policies on the role you connect apply as normal.
Frequently asked questions
Ready to build with Schedule?
Start building workflows in minutes with our visual builder. No code required.