> For the complete documentation index, see [llms.txt](https://notara.gitbook.io/notara-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notara.gitbook.io/notara-docs/automations.md).

# Automations

Automations let the Notara agent work for your team without anyone needing to ask. Two types:

* **Scheduled Tasks** — run the agent on a cron schedule (daily digests, weekly reports, periodic audits)
* **Webhooks** — trigger the agent from an external system (GitHub PR merged, Stripe payment received, anything that can POST to an HTTP endpoint)

## Why Automate?

The Notara agent is most valuable when it's proactive — not just answering questions but surfacing insights, summarizing activity, and flagging issues without being asked. Automations are how you build that into your team's workflow.

**Common use cases:**

| Automation                | Trigger                         | Output                                        |
| ------------------------- | ------------------------------- | --------------------------------------------- |
| Weekly engineering digest | Every Monday 8am                | Sprint summary → #engineering                 |
| Daily error brief         | Every day 9am                   | Last 24h errors from logs → #oncall           |
| MRR report                | 1st of every month              | Stripe revenue summary → #growth              |
| PR activity digest        | Every weekday 5pm               | Open and merged PRs → #engineering            |
| Competitor monitor        | Every Monday 9am                | Perplexity news search → #growth              |
| Stripe payment alert      | Stripe webhook → Notara webhook | New customer notification → #growth           |
| GitHub PR merged          | GitHub webhook → Notara webhook | Summary + Linear update prompt → #engineering |

## The Automations Page

Navigate to **Automations** in the dashboard sidebar. The page shows two tabs:

* **Scheduled** — cron-based tasks
* **Webhooks** — incoming webhook endpoints

Each automation shows its status, last run time, next scheduled run (for scheduled tasks), and a **Run Now** button for immediate execution.

## Automation States

| State        | Meaning                                                          |
| ------------ | ---------------------------------------------------------------- |
| **Active**   | Running on schedule (or webhook enabled)                         |
| **Draft**    | Created but not enabled — common for automations created via MCP |
| **Paused**   | Was running, manually disabled                                   |
| **Archived** | Disabled and archived — won't run; can be restored               |

Draft automations are those that haven't been explicitly enabled via the dashboard. Any automation created programmatically (via the MCP `create_automation` tool) starts as a draft — enabling it requires a human to confirm in the dashboard. This is by design: the dashboard confirmation is the config-time authorization that allows it to run as a system actor.

## Run Now

The **Run Now** button (lightning bolt icon) executes the automation immediately, outside of its normal schedule. Useful for:

* Testing a new automation before it runs on schedule
* Running a digest on demand (e.g., before a leadership meeting)
* Re-running after a failed run

The run appears in the run history log with a "manual" trigger label.

## System Actor

Scheduled automations run as the **system actor** — not as a specific user. This has important implications for tool permissions:

* **Approval prompts are bypassed**: write tools don't trigger Slack approval DMs. The admin authorized the task at configuration time, which counts as the approval.
* **Destructive tools**: still require that the automation be configured by an admin. The system actor does not bypass the fundamental `admin_only` restriction — it just means the confirmation flow is handled at setup time, not at runtime.

If you want a scheduled task to be cautious about writes, use a skill with tighter permission bindings, or set the channel's tool permission overrides to require\_approval for the relevant tools.

→ [Scheduled Tasks](/notara-docs/automations/scheduled.md)\
→ [Webhooks](/notara-docs/automations/webhooks.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://notara.gitbook.io/notara-docs/automations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.