> ## Documentation Index > Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt > Use this file to discover all available pages before exploring further. # Automations > Have Mole Agent do a job with nobody in the chat: on a schedule, for new incidents, when a CI/CD job calls, or by hand. Every run is kept as a chat. An automation asks Mole Agent the same task each time it starts: check the health of the services every morning, investigate each new critical incident, or look at a deploy when the pipeline calls. Mole Agent works on it the way it works in a chat, with the tools, skills, and knowledge of the automation's scope, and the run is kept as a chat that the people who see the automation can open. When the run ends, the result goes to the notify channels you chose, and an automation started by incidents can write the incident's RCA. ## Before starting * Enable at least one AI model under **Mole Agent → Settings → Models & reasoning**. See [Mole Agent](https://docs.molesignal.com/en-US/agent#set-up-a-model-provider). Without one, a run fails and says why. * Check the permissions: | Task | Permission | | - | - | | See automations and their runs, and open the chat of a run | `agent.use`, and the scope: see [Whose it is](#whose-it-is) | | Create, edit, switch on, run now, and manage the API token | `agent.automations.manage`, granted to the owner, admin, and editor roles by default, and the scope | | Switch off and delete | The same, or `agent.manage` for any automation you can see | | Choose notify channels in the form | `alerts.read`, which lists the notify connectors | ## Create an automation Open **Mole Agent → Automations → New automation**, and start from a blank automation or a template: | Template | Starts | Does | | - | - | - | | **Incident analysis** | New incidents of severity error or critical | Investigates the incident with tools: reruns the query that triggered it, looks at error logs, traces, APM, and the service topology, gives the likely root cause with its evidence, and writes it as the incident's RCA. | | **Daily health check** | Weekdays at 09:00 | Checks error rates, latency, error patterns, and open incidents of the last 24 hours, and says what needs attention. | | **Weekly alert noise review** | Mondays at 10:00 | Finds the alert rules that fired most, flapped, or were never acted on last week, and proposes how to tune each. | | **Weekly on-call load** | Mondays at 10:30 | Sums up the incidents per person and schedule, night-time pages, and response times, and suggests how to lower the load. | | **Change impact check** | An API call | Compares the services a deploy touched before and after it, and says whether it caused a regression. | The form has these fields: | Field | Description | | - | - | | **Name** | Unique in the organization. | | **What to do** | The task, up to 8000 characters. Mole Agent is asked it each time, as in a new chat. | | **Description** | One line on what the automation is for. | | **Whose** | The scope, chosen when the automation is created: yours, one of your teams', or the organization's. | | **Starts** | On a schedule, new incidents, an API call, or by hand. See [What starts it](#what-starts-it). | | **Time limit** | 5 to 60 minutes, 10 by default. A run that takes longer is stopped and counted as failed. | | **On** | An automation that is off starts only when someone runs it now. | | **Notify channels** | Up to five fixed addresses or groups on notify connectors. | | **Write the conclusion as the incident's RCA** | For an automation started by incidents. | An organization has at most 50 automations. **Clone** in a row's menu opens a copy in the form, switched off, to save under another name or in another scope. ### Whose it is The scope decides what a run can use and who can see the automation. It cannot be changed after the automation is created; clone it to use another scope. | Scope | A run uses | Who sees it | | - | - | - | | Personal | The organization's and your own skills and MCP servers, the organization's knowledge, and your memory | You, and holders of `agent.manage` | | Team | The organization's and the team's resources and knowledge, and the team's memory | The team's members, and holders of `agent.manage` | | Organization | The organization's resources and knowledge only. Its runs keep no memory. | Everyone with `agent.use` | A run of an organization automation started by an incident uses the incident's team, taken from its escalation policy: the first team it pages, else the team of the first on-call schedule. When there is none, the run stays in the organization's scope. ### Who it runs as An automation runs as the person who saved it last: with that person's permissions, read again at each run, and with their own credentials on MCP servers that take one from each member. Saving it makes you the one it runs as, and the form says so. Saving with an API token is refused, because a token stands for its role and not for the person who made it. When that person can no longer use Mole Agent in the organization, each run fails with that reason until someone who may saves the automation again. ## What starts it | Trigger | When it runs | | - | - | | **On a schedule** | At the times of a five-field cron expression (minute, hour, day of month, month, day of week) in a time zone, at most once every 15 minutes. In the day of week, 0 and 7 are Sunday. Limit either the day of month or the day of week, not both. When the previous run is still going, the next one is skipped. | | **New incidents** | For each incident created after the automation was saved or switched on that matches every filter you fill: severities, alert rules, affected services, and labels with equal values. An incident is analyzed once, and incidents of the same group, which share the rule and the labels, once within 30 minutes. | | **API call** | When an outside system sends its token. See [Start it from CI/CD](#start-it-from-ci/cd). | | **By hand** | Only when someone runs it. | **Run now** in a row starts any automation that is on or off, as the person it runs as, at most once a minute. ## Runs **Runs** in a row lists the last 100 runs, newest first: how each went and why, what started it, the start of the answer, channels that were not reached, and **Open the run**, the chat that holds the whole run. That chat is not in the chat list and cannot be continued; to ask again, run the automation. Nobody can answer during a run. When Mole Agent asks a question, it goes on with its own judgment; a tool that needs someone to confirm it is not run; and an MCP server that needs the run's person's own credential, which is not saved, is not used. Mole Agent says so in its answer, and the run is marked as needing someone. | Status | Meaning | | - | - | | **Running** | Mole Agent is working on it. | | **Succeeded** | It answered, and the notices and the RCA went out. | | **Partly done** | It answered, but a notice was not sent or the RCA was not written. | | **Needs someone** | It answered, but a question, a confirmation, or a credential was needed and nobody could give it. | | **Failed** | It did not answer: the model or a tool failed, it ran past its time limit, no model is on, or the person it runs as can no longer use Mole Agent. | | **Skipped** | It did not start: the organization's token budget for the day is used up, the previous run had not finished, or the incident was analyzed a moment before. | | **Stopped** | Someone stopped it, or the server running it stopped. | The model calls of runs count toward the organization's daily token budget and show as **Automations** in the usage by source. ## Notices and the incident's RCA A run that succeeds, needs someone, or fails sends a notice to each channel: the automation's name and how the run went, the start of the answer, the reasons, and a link to the run. The notice is written in the language of the person who saved the automation and appears in the delivery records like other notifications. An automation started by incidents with **Write the conclusion as the incident's RCA** on writes Mole Agent's answer as the incident's RCA, which the incident page shows. An RCA that someone wrote from a chat stays. While an organization has such an automation on, the built-in RCA generation leaves the organization's incidents to it, so an incident is not analyzed twice. The **Incident analysis** template is set up this way. ## Start it from CI/CD For an automation started by an API call, open **API token** in its row's menu and select **Make a token**. The token is shown once; making another one replaces it at once, and **Take the token away** removes it. Send it with the deploy, and describe the change in `text`: ```bash theme={null} curl -X POST "https://molesignal.example.com/api/v1/public/automations//trigger" \ -H "Authorization: Bearer msauto_..." \ -H "Content-Type: application/json" \ -d '{"text": "Deployed checkout-api v42 at 14:05"}' ``` `text` is optional and at most 8000 characters. Mole Agent reads it as data about the run, not as instructions. The answer is `202` with `run_id`, `status`, and `chat_url`. A wrong token or an unknown automation answers `401`; an automation that is off or not started by API calls answers `409`; a second call within 10 seconds answers `429`. ## Look back at how Mole Agent is used `/insight [days]` is a built-in skill that reviews the last 30 days, or the days you give, of Mole Agent in the chat's scope: what was asked, how the answers and automations went, what was rated unhelpful and why, which tools failed often, and which skills were used. It ends with at most five changes worth making, such as a knowledge file to write or an automation to fix. It changes nothing. A team chat looks at its team, and a personal chat at you and your teams. Use it in a chat, or as the task of a weekly automation. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.