Automations

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

Outcome

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

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.

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; 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
• Run inspection
• Notifications
• Triggers
• Automation operations reference

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.

What a fire actually runs

See Automation operations: What a fire actually runs.

The provider pin — fail closed on model drift

See Automation operations: Provider pin.

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.

Reliability semantics

See Automation operations: Reliability semantics.

API surface

See Automation operations: API surface.

Recipes — reusable starting points in Automations

See Automation operations: Recipes.

Atomicity (trigger-bound recipes)

See Automation operations: Atomicity.