A completed Browser or Computer result with evidence offers Make recurring. This saves its verified instructions as a routine, then opens a separate schedule review. No schedule is enabled until you select Enable schedule. Saved routines also offer Schedule, using the same review.

The selected timezone is saved even when quiet hours are off. Reopening a schedule on another device keeps that timezone. Older schedules use their saved quiet-hours zone, or UTC when no timezone was recorded.

1. 1Choose an interval and timezone. Computer supports daily or weekly runs; eligible public read-only Browser routines also support hourly and six-hour checks.
2. 2Review the complete task, existing recurring details, quiet hours, failure pause policy, per-run limits, and estimated first run.
3. 3Confirm the reviewed version. If the routine changed, reload its current version and review again. If confirmation is uncertain, retry the same request before creating another schedule.

• The first-run time is an estimate, not a reservation. Browser becomes eligible after confirmation; Computer becomes eligible one interval later. Quiet hours and runner availability can delay either. Intervals are elapsed hours, not fixed local clock times across daylight-saving changes.
• If a Browser monitor already exists, the review shows its current schedule instead of offering another. Its original reviewed recipe is unchanged by edits to the saved routine. Pause or resume the existing monitor there; removing it requires confirmation. If an update cannot be confirmed, refresh before changing it again.
• Pausing a Browser monitor stops future checks; a check already in progress can finish. Refresh its status before removing it. Checks that need attention remain paused until you review the source Thread and explicitly resume. Removal is unavailable during a current check. If cleanup is interrupted, checking stays stopped and Retry removal finishes clearing the private monitor history without deleting the saved routine or original Thread results.
• Existing Computer details and safety settings are loaded for review. Updating enables that schedule in the current Thread. Clearing recurring details removes them from subsequent runs.
• These direct routines return results to the Thread. They do not automatically send to Slack or another connected app. Computer external actions still require exact approval; a saved sign-in does not make a Browser routine eligible for unattended work.
• Hosted access and usage limits still apply. Saving a routine is not proof that a scheduled run completed.

Open an existing Browser routine in Scheduler, then choose Edit schedule on its monitor. Change the interval, timezone, quiet hours, automatic failure pause policy, or report settings. Review changes shows the old and proposed settings before Save changes updates that same monitor.

• Editing keeps the original reviewed recipe, inputs, per-check limits and history. A paused monitor stays paused; saving is not permission to resume it.
• A check already in progress continues with the same run identity. New timing applies when it finishes, and the selected failure policy applies as checks finish. Existing consecutive failures are not reset.
• Quiet hours can be turned off explicitly. Your selected timezone is retained even without quiet hours. Displayed next-check times are estimates; quiet hours and runner availability can delay them.
• Checking more often can increase hosted usage. Changing a schedule does not add automatic delivery to another app.
• If another tab changed the schedule, choose Check current schedule and review again. If saving is unconfirmed, Retry confirmation reuses the same change; Check current schedule loads what is stored. Do not assume that a timed-out save was rejected.

After a Browser or Computer result has been delivered successfully to Slack with a provider receipt, Make recurring can offer that exact workspace and channel. Choose Keep in this Thread to leave delivery off, or select the previous destination and review the policy before enabling.

• Browser can prepare a report only when findings change, or after every completed check. Changed-only reporting establishes a quiet baseline first. Computer can prepare a report after each completed run. Failed or partial results are not sent as successful reports.
• Every new report waits in the Thread for exact approval of its destination and entire message. The approval for an earlier report is never reused. Changing a Room's default channel does not redirect scheduled reports; reconnect the original scope if it is no longer available.
• A temporary save failure retries the same completed result and delivery preparation, not another provider task or external send. Unknown send outcomes still require reconciliation.
• Existing Computer schedules restore their destination for review and can turn future report preparation off. For Browser, choose Edit schedule, then Reports to select a prior verified Slack destination, change the policy, or choose Keep in Codelit. Review and save without deleting the monitor. If another channel is missing, send this routine's original verified result there with exact approval first, then retry destinations.
• Browser report edits apply to future checks. A running check keeps its original destination and reporting policy, including after a publication retry. Existing message reviews are not cancelled or redirected. A paused monitor stays paused. If destinations cannot load, you can keep the current destination or turn future report preparation off without losing your timing changes.

Open Automate from the Agent Team toolbar or Automate this proof from a completed personalized proof, then choose Scheduled, App event, or Webhook. Scheduled supports hourly, every six hours, daily, or weekly work. App event watches one exact connected source. Webhook creates a private URL plus a one-time HMAC secret.

• GitHub: new issues or failed workflow runs in one consented repository.
• Slack: a member command or matching message in one consented channel.
• Gmail and Outlook: messages returned by one bounded mailbox query.
• Microsoft Teams: a member command or matching message in one selected Team channel.
• Sentry: issues returned by one bounded organization query.

Every hosted trigger has a daily run cap and replay window. Signed webhooks can also match one safe JSON field before spending a run. Optional quiet hours use the selected IANA timezone; matching events are encrypted, held, and resumed after quiet hours rather than discarded.

• Duplicate delivery IDs do not create a second run.
• At most two runs for one automation may be active at once.
• Provider checks do not call a model until a new matching event is claimed.
• Bot-authored Slack messages are ignored to prevent notification loops.
• Pausing an automation stops schedules, provider checks, tests, and inbound webhooks.

Expand an automation in Projects to send a manual trigger test through the same policy, review the latest 50 trigger deliveries, read the latest run log, pause or resume work, and inspect trigger health. If that automation has a signed result webhook, the same view can send a signed result test, replace the endpoint, rotate its one-time secret, disable delivery, and retry a failed terminal event without rerunning the Agent Team. Trigger receipts and result status are labeled separately. Delivery receipts are retained for 30 days. Green is healthy, amber is delayed, and red needs attention.

The bell in the global toolbar shows running, completed, failed, approval-needed, and Team Health work. Open Agent Team Inbox for the complete queue, private receipts, source-delivery state, and recoverable reply failures. Green means active or newly completed work, amber means an approval or health issue needs review, and red means a task failed or Team Health found a critical condition. Clearing a finished task permanently dismisses that task for the account; durable run receipts remain in the Inbox.

Configure email, Telegram, a per-automation result webhook, or Reply in the source conversation. Slack and Microsoft Teams post inside the original thread; Gmail and Outlook use their native reply APIs on the exact source message. Every reply contains only status, approximate cost, and an authenticated private receipt link. Background-task email turns bounded structured results into a short human-readable summary and returns to the exact Agent Team, board, or architecture project where the task started. Webhook deliveries use a stable delivery ID and an HMAC signature so receivers can verify and deduplicate retries. Local Lite, open-tab schedules, and ordinary browser task results never use a hosted result destination.