> ## Documentation Index > Fetch the complete documentation index at: https://help.teable.ai/llms.txt > Use this file to discover all available pages before exploring further. # Routine > Let Cuppy run a prompt on a schedule and review the result of every run. Available on all Cloud plans; Self-Hosted requires Business or higher. A routine hands a prompt to Cuppy and repeats it, either on a schedule or whenever a connected third-party app reports an event. That suits work nobody needs to trigger by hand: a daily report, a periodic cleanup of expired records, filing a new email as it arrives. Every run is a full AI chat, so a routine can do everything AI chat can, including reading and writing tables, calling skills, and producing files. A routine is a resource inside a project and sits in the left sidebar next to tables, apps, and automations. An automation runs the steps you configured in advance, while a routine runs a prompt the agent interprets itself. Both can fire on a schedule, and both can fire on an event from a connected third-party app. Use an automation when you need fixed steps and predictable output; use a routine when you want the agent to decide what to do with the current data each time. ## Create a Routine In the left sidebar, click **+** and choose **New routine**. Describe what each run should do in **Prompt**. The prompt is the entire instruction for a run, so state where the data comes from, how to process it, and where the result goes. For example, "Summarize records added to the Tasks table yesterday, group them by owner, and write the summary to the Daily Report table." Under **Trigger**, choose **On a schedule** or **On a connector event**, then fill in the settings that kind needs. Click **Activate**. The configuration must be saved first: **On a schedule** needs a future occurrence, and **On a connector event** needs a usable account. ## Settings Besides the prompt and the trigger, the form carries these settings: | Setting | Description | | - | - | | **Model** | The model and effort level this routine runs on. Leave **Default model** to use the space's default chat model | | **Chat** | **New chat for every run** keeps runs independent of each other; **Continue the previous run's chat** carries the context of earlier runs forward, which suits work that needs to refer to the last result | | **Starting** / **Ending (optional)** | The bounds of the schedule, used by **On a schedule** only. Without an end time the routine keeps running indefinitely | The model and effort level are recorded when you save, so run history shows what each run actually used. ### Trigger **On a schedule** runs the routine at the times you set, configured under Schedule below. **On a connector event** runs it once whenever a connected third-party app reports an event, such as a new email or a new issue. Pick the app, the event, the **Account** that receives it, and whatever parameters the event takes; it is configured exactly like the automation trigger, described in [When Connector Event Received](/en/basic/automation/trigger/external/connector-event). A routine on this trigger has no **Next run** time and uses neither the schedule nor the bounds. If the account grant is revoked, the connected account is removed, or the app stops the subscription, the routine reports **Subscription disconnected** and stops receiving events, and Teable notifies the member who last updated it. Reconnecting the same account rebuilds the subscription on its own; to use a different one, pick another account and save. ### Schedule The schedule is used by **On a schedule** only. Pick a frequency from the presets: **Hourly** at a given minute, **Daily** and **Weekdays** at a given time, **Weekly** on a weekday and time, **Monthly** on a day and time. For anything more specific, choose **Custom (RRULE)** and write an RFC 5545 rule, such as `FREQ=DAILY;BYHOUR=9;BYMINUTE=0`. A custom rule has these limits: * The frequency must be `HOURLY`, `DAILY`, `WEEKLY`, `MONTHLY`, or `YEARLY`, and two runs must be at least 1 hour apart. * You can use `INTERVAL`, `COUNT`, `BYDAY`, `BYMONTHDAY`, `BYMONTH`, plus one `BYMINUTE` and one `BYHOUR`. `COUNT` tops out at 1000, and `COUNT` or `INTERVAL` requires a **Starting** time. * The timezone and the bounds come from the form, so `TZID`, `DTSTART`, `UNTIL`, and `BYSECOND` are rejected. For a schedule that runs only once, use a custom rule with `COUNT=1`. A schedule is evaluated in the timezone of whoever created the routine and does not follow the viewer. The **Next run** time shown in the interface is already converted to your local time. ## Drafts, Updates, and Running Now A new routine is a draft and does not run by itself until you activate it. When you edit an active routine, the change is also saved as a draft while the live version keeps running on the old configuration: click **Update** to apply it, or **Discard changes** to drop it. **Run now** executes once without waiting for the trigger, which is useful for checking a prompt. A routine cannot be run by hand again until its previous run has finished. On a connector-event routine that is not yet active, **Run now** shows **Waiting for an event** instead: go into the app and do something that fires the event, and Teable uses the one it receives for a single run, which then appears in run history. Click **Stop waiting** to end the wait early. An active routine already receives its events, so it neither needs nor allows this. Turn the switch off to deactivate. The routine stops firing, and existing run history is kept. ## Run History Open the routine and switch to **Run history**. The run list can be filtered by status and time range, which helps locate a particular failure; selecting a run shows its **Run ID**, its **Trigger**, and the full conversation of that run. **Trigger** reads **Scheduled**, **Event**, or **Manual**, and a **Scheduled** run also shows the **Planned** time it served. Runs are reported as **Queued**, **Running**, **Completed**, **Failed**, or **Canceled**. **Canceled** appears when someone interrupted that run, or when the routine or its project has been deleted. A **Failed** run states its reason, and each reason calls for a different response: | Message | Meaning | What to do | | - | - | - | | **Run failed** | The run started but hit an error | Open the conversation for that run and judge from the failure point whether the prompt or the data is at fault | | **Skipped: not enough credits** | Credits ran out, so the run never started | Top up the space's credits | | **Skipped: the previous run was still in progress** | The previous run had not finished, so this occurrence was skipped | Lower the frequency, or reduce how much one run processes | | **Skipped: timed out waiting in the queue** | The run waited too long in the queue and was skipped | Occasional occurrences need no action; a recurring one means too much is scheduled at the same time, so stagger the schedules | The conversation of a run is read-only. Members who can edit the routine may continue it at the end to investigate how a particular run proceeded. Each run's conversation also appears in the chat history, owned by whoever last updated the routine. Scheduled and manual runs carry the routine's name; event-triggered runs are renamed automatically based on the prompt and the event received, so each event is easy to tell apart in the history. Deleting a routine does not delete these conversations: they keep their names and become ordinary chats. Run history requires permission to edit the routine. A project's owner and creator can create, edit, and delete routines; other collaborators have read access. ## Failure Alerts and Automatic Deactivation Teable sends a notification when a run fails or credits run out. It goes to the member who last updated the routine, named under **Notifications will be sent to** at the top of run history. Failure notifications are not sent every single time, so that a long run of failures does not flood the recipient. After 5 consecutive failures the routine is deactivated automatically and a separate notification goes out. Turn the switch back on once the problem is fixed; the count resets after the next successful run. Not every unsuccessful run counts toward that total: runs skipped because the previous run was still in progress or because they timed out in the queue, along with **Canceled** runs, are not failures and produce no notification. A credit shortfall does count, so leaving credits unfunded eventually deactivates the routine. ## FAQ Yes. Every run is an AI chat and is billed against the space's credits by actual usage, listed under type **Routine** in **Credit usage summary** on the billing page. When credits run out the run is skipped and a notification is sent, and repeated skips eventually deactivate the routine. No. The change is saved as a draft and only reaches the live version when you click **Update**. A run already under way keeps the configuration it started with. Scheduled ones do. After a template install they are switched on the way its workflows are, and a schedule with no future occurrence stays a draft. Connector-event routines are not switched on: credentials do not come over with a template, so pick one of your own accounts before activating. When the context approaches its limit, Teable compacts the conversation, so runs are not interrupted by it. Choose **New chat for every run** when each run should start from a clean context. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.