> For the complete documentation index, see [llms.txt](https://notara-1.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-1.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)