---
title: "Automations"
description: "Run agent prompts on webhooks and schedules"
canonical_url: "https://hoplite.sh/docs/automations"
markdown_url: "https://hoplite.sh/docs/automations.md"
---

# Automations
URL: /docs/automations
LLM index: /llms.txt
Description: Run agent prompts on webhooks and schedules
Related: /docs/threads/run, /docs/prompting, /docs/integrations/slack, /docs/integrations/linear

# Automations

Automations run an agent prompt against a project without anyone typing it — triggered by an incoming webhook or on a schedule. Use them for recurring chores (dependency bumps, triage sweeps, report generation) or to wire external systems into Hoplite.

## Create an automation

Each automation belongs to a project and has:

| Field | Purpose |
| --- | --- |
| Name | Identifies the automation |
| Enabled | Toggle it on or off |
| Prompt | What the agent should do, written exactly like a thread message |
| Run title (optional) | Title for the runs it creates |
| Trigger | A webhook or a schedule |

Workspace owners, admins, and members can create, run, enable, edit, and delete
automations. Viewers can inspect automations and their run history but do not
see mutation controls.

<Callout type="tip" title="Write prompts like standing orders">
The prompt runs unattended, so spell out the goal, the constraints, and what "done" looks like — e.g. "Check for outdated dependencies with known CVEs. If any exist, upgrade them, run the test suite, and open a draft PR summarizing the changes. If tests fail, stop and report instead of forcing the upgrade."
</Callout>

## Trigger from a webhook

A webhook automation has a fixed delivery endpoint and a bearer token. Send the token in the `Authorization` header:

```bash
curl -X POST https://api.hoplite.sh/api/automations/webhooks \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"event":"deploy.failed"}'
```

An authenticated `POST` runs the automation's prompt as a new agent run. The token is scoped to that one automation — it can't read data or trigger anything else. Treat it like any other secret and only copy it into the system that delivers the webhook.

### Manage the token

- Open **Edit automation** to review and copy the request, endpoint, or bearer token again
- **Rotate** the token any time from the automation's page; rotation replaces the stored credential, so the old token stops working immediately
- Legacy `hwa_` credentials that cannot be displayed must first be rotated, which invalidates the old token

<Callout type="warning" title="Legacy token-in-path URLs">
Legacy `hwa_` token-in-path URLs remain available during a compatibility window; the legacy route can be removed after it reports no deliveries for 90 consecutive days. New and rotated `hwa2_` credentials are header-only and are rejected in URL paths.
</Callout>

## Run on a schedule

Scheduled automations run on either:

- **Cron** — a standard 5-field cron expression with an IANA timezone (e.g. `0 9 * * 1` in `Europe/Dublin` for Mondays at 9:00)
- **Interval** — a fixed period, minimum 1 minute

The automations page shows each automation's last run, its status, and when it fires next.

## Inspect the runs

Every trigger does the same thing: starts a new thread and agent run in the project with the automation's prompt. The run behaves like any other — full [sandbox](/docs/sandboxes), full [tool catalog](/docs/agent/tools), and a complete activity timeline. The run history on the automations index and detail pages keeps its thread link when the run fails and shows the classified cause when one is available, such as **failed: AI provider usage limit reached**, so you can triage the failure before opening the thread. Automation-started threads are hidden from the main thread list by default; use **Include threads started by automations** in the [thread filter](/docs/threads/manage#thread-list-groups) to include them.

## Sitemap

See the full [sitemap](/docs/sitemap.md) for all pages.
Well-known sitemap: [/docs/.well-known/sitemap.md](/docs/.well-known/sitemap.md).