# Automations > Run reports or reviewable changes on a schedule or in response to an event, with explicit connectors, permissions, limits, and run history. An Automation runs a job without you asking each time. A schedule or an event starts it, the agent follows your instructions, and Estelle records the result. Use Automations for recurring reports, event triage, and changes that should arrive as pull requests. Open **Dashboard → Automations**. Each saved run is linked from the automation's row, and finished runs can also send notifications. ## Choose how to create one - **From a template**: start with a prepared trigger and task, then connect what it needs or choose **Customize**. Read the template's own description and **It will not** limits; do not rely on its name alone. - **Describe it**: write the trigger and desired result in plain English, then choose **Fill in the form**. Review and edit every inferred field before saving. - **Create manually**: choose the triggers, instructions, agent, connectors, delivery, notifications, and limits yourself. You can also describe an Automation in [Agent mode](https://docs.fatelabs.ca/agent-mode) and allow its proposal. ## Create an automation ### Set the trigger Add at least one trigger. The automation runs when **any** of its triggers fires. For a schedule, choose hourly, daily, weekly, a one-time run, or a custom cron expression, and set the time zone. Read the schedule summary before saving. A one-time automation switches off after its first run. For an event, choose the source and fill in its required filter, such as an issue label, Slack keyword, or app trigger. GitHub events require the Estelle GitHub App. A webhook automation provides a signed URL after creation. Monitoring events can start from a monitor alert or a new production error. ### Write the instructions and choose the agent Say what the agent should read first, what it should do with each event, and what a useful result contains. Add an optional step before the agent if every run needs the same preparation. A coding agent can work with a repository checkout. **Estelle (desktop)** is for browser and desktop work and does not receive a repository checkout. A repository is optional for work that does not need one. ### Choose delivery and connections Choose **A report** when the run should change nothing, or **A pull request** when it may change code and open a reviewable change. Select only the connectors and tools the task needs, and connect any that are missing. Choose where finished runs are announced: in Estelle, Slack, or a webhook, where available. ### Set boundaries and save Review **Advanced** when the job needs a network allowlist, a Silo environment, a spend cap, a rate limit, or a concurrency queue. An enabled network allowlist with no entries blocks every destination after agent setup. Choose **Create automation** and read the saved receipt. It shows the stored triggers, tools, connectors, and autonomy ceiling, plus any unavailable connections or triggers. If write access is requested, acknowledge it explicitly first. **Note:** Check the saved configuration, not just your original description. The receipt is also where Estelle reports a lower effective autonomy ceiling or a schedule that differs from the one requested. ## Control what a run may change An event can contain someone else's words. For that reason, a run started by an outside event, such as a GitHub event, Slack message, webhook, or connected-app event, is **read-only**. It can investigate and report, but cannot comment, push, merge, or deploy. Other runs stay within the automation's effective autonomy ceiling and your account settings: - **A report** changes nothing. - **A pull request** can push a working branch and open a pull request after you acknowledge that access. A person reviews it by default. - **Merge when proven** is offered only for a coding agent with a repository and pull-request delivery. It also requires auto-merge to be enabled for that repository and all of its proof conditions to pass. Otherwise the pull request stays open for you. Automations never deploy. Auto-merge is a separate opt-in, not a consequence of creating an automation. See [Autonomy](https://docs.fatelabs.ca/autonomy). ## Run and inspect an automation Use the row's play button for **Run now**. A paused automation must be resumed first. The switch pauses or resumes future triggering; it does not erase run history. Open **⋯ → Run history** to see: - each run's state, trigger, execution target, and reason; - a link to its session, or to its Twice run when one was produced; - the delivery log, including reports or changes that were refused, filtered, queued, or delivered; - **Re-run** where supported, using the original event data or a manual run as appropriate. A run's state and a delivery's state answer different questions. The agent may have finished its investigation while the requested delivery was refused. Read both before calling the automation successful. ## Maintain automations - **Save as template** adds the current configuration under **Templates → Mine** for reuse. - **Open latest session** jumps to the newest recorded work. - **Delete** stops future triggers. Past sessions remain on the Sessions board. - **Auto-paused** means repeated failures caused Estelle to stop the automation. Read the recorded reason, fix the cause, and resume it deliberately. If a trigger cannot fire on this server, the row and creation receipt say **cannot fire yet** or **Not firing**. An enabled automation with such a trigger is not proof that events will arrive. ## Limits **Limit:** An automation is not a deployment mechanism. Keep its result as a report or a reviewable pull request unless you have deliberately configured proven auto-merge. - Each run can use credits and any provider access required by its chosen agent. See [Plans and credits](https://docs.fatelabs.ca/plans). - The **Push** trigger applies to pushes on any branch; branch filters are not enforced. - Some schedule, connector, notification, and management options depend on the current server. Disabled options and receipts explain what is unavailable rather than implying it will work. - History is bounded by what the page reads. If it says older runs may exist, use the linked session records rather than treating the visible list as complete. ## Related - [Silos](https://docs.fatelabs.ca/silos): The cloud machines where automation runs work. - [Autonomy](https://docs.fatelabs.ca/autonomy): Set pull-request and auto-merge permissions. - [Channels](https://docs.fatelabs.ca/channels): Connect Slack, Linear, and iMessage.