# Automations

> Outpost automations run a saved prompt against one project on a schedule and keep every result available from Activity.

Outpost automations run a saved prompt against one project on a schedule and
keep every result available from Activity.

<!-- SOURCE: container/dashboard/jobs.py, container/dashboard/scheduler.py, container/dashboard/jobs_api.py, container/dashboard/presentation.py, container/dashboard/templates/landing_body.py, container/dashboard/templates/landing_css.py, container/dashboard/templates/landing_js.py -->

## Outcome

Create a bounded automation, understand its next run, and inspect or recover it
without learning the scheduler's storage vocabulary first.

<a id="creating-a-job"></a>

## Fast path

1. Open **Automations** and choose **New automation**.
2. Describe the outcome under **What should Kin do?**
3. Choose the project whose files the run may use.
4. Give the automation a readable name.
5. Choose an interval, daily/weekly time, weekdays, or a one-time run; confirm
   the plain-language next occurrence.
6. Save. Use **Run now** for an immediate first result.
7. Open **Results** or Activity to inspect the report and evidence.

[![Outpost New automation form with a morning project brief, generic Guide project, readable name, and the verified example account.](/docs-assets/kin/assets/screenshots/outpost_automation_create.png)](/docs-assets/kin/assets/screenshots/outpost_automation_create.png)

*The ordinary form leads with work, project, schedule, and name. Execution
limits remain available under advanced options.*

## Choose the schedule

| Choice | Use it for | Stored shape |
|---|---|---|
| Interval | Every N minutes, hours, or days | `every` |
| Daily / weekly / weekdays | Familiar local wall-clock schedules | `cron` |
| One time | A single future run | `at` |

The browser timezone is the default and the preview uses the same computation
as the saved schedule. Advanced options expose mode, timeout, retries, token
budget, provider pin, and raw cron when the ordinary choices are not enough.

## Inspect and recover

Each automation row shows enabled/paused state, next occurrence, last outcome,
and actions:

- **Run now** creates an immediate run without changing the schedule.
- **Pause** prevents future fires without deleting history.
- **Results** opens Activity filtered to this automation.
- **Edit** reopens the same form and preserves untouched advanced values.
- **Re-pin** deliberately adopts a newly served model after provider drift.

Unattended execution is deliberately bounded. A run is single-flight; missed
times coalesce; retries stop; timeouts kill the whole child process group; and
repeated failures disable the automation with a visible reason. A question for
you becomes a halted **needs you** result rather than an infinite retry. Its
answer can continue only that still-current halt. Stopping the run first
permanently retires the item and any unspent approval while preserving the
history; a stale answer cannot restart it. A cancelled one-shot is permanent:
create a new job for a fresh attempt rather than re-enabling the old identity.

## Recipes

A recipe is a visible starting point for a useful automation. Choosing one
prefills the prompt and schedule; review and edit them before enabling. The
created automation retains the recipe id/version so Outpost can show when the
catalogue has changed without silently rewriting your saved prompt.

## Alternative methods

#### Run now


Use an automation's **Run now** action when the saved prompt/project are
right but you do not want to wait for the next occurrence.

#### Recipe


Start from the gallery, inspect the resulting prompt and schedule, then
enable it. Recipes are templates, not hidden behavior.

#### Machine door


External systems can submit bounded jobs through Outpost v1. Use the
[protocol](/docs/kin/protocol/); do not reproduce browser CSRF routes in
an integration.

## Troubleshooting

- **The time is wrong:** check the displayed IANA timezone and preview before
  saving.
- **A run was skipped for drift:** the concrete served model changed. Review
  it, then use **Re-pin** if the change is intentional.
- **The automation disabled itself:** fix the visible repeated-failure reason,
  then re-enable; this resets the consecutive-failure count.
- **A run says needs you:** open the Activity item and answer it. Human gates
  are not retried automatically.
- **Interactive Kin feels slow:** the operator can tune Outpost's background
  governor; see the maintainer reference below.

## Reference

- [Outpost overview](/docs/kin/guide/outpost/)
- [Run inspection](/docs/kin/guide/outpost/#run-inspection)
- [Notifications](/docs/kin/guide/messaging/)
- [Triggers](/docs/kin/guide/triggers/)
- [Automation operations reference](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md)

## Forwarded technical anchors

The prior all-in-one page's implementation sections remain available for
existing links.

### Exact schedule contract

See [Automation operations: Exact schedule contract](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#exact-schedule-contract).

### What a fire actually runs

See [Automation operations: What a fire actually runs](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#what-a-fire-actually-runs).

### The provider pin — fail closed on model drift

See [Automation operations: Provider pin](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#the-provider-pin-fail-closed-on-model-drift).

### The governor — cross-run GPU fairness

The name preserves the original vLLM-era anchor; current DS4 operation is
provider-independent background admission. See [Automation operations:
Governor](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#the-governor-cross-run-gpu-fairness).

### Reliability semantics

See [Automation operations: Reliability semantics](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#reliability-semantics).

### API surface

See [Automation operations: API surface](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#api-surface).

### Recipes — reusable starting points in Automations

See [Automation operations: Recipes](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#recipes-reusable-starting-points-in-automations).

### Atomicity (trigger-bound recipes)

See [Automation operations: Atomicity](https://github.com/kinra-ai/kin/blob/dev/docs/internals/automation-operations.md#atomicity-trigger-bound-recipes).