Skip to main content

Automations

Automations review and sort recordings and events in the background as data arrives, so engineers don't review everything by hand. An automation is a saved prompt plus an optional trigger. Each time it fires is an automation run. Foxglove runs an AI agent against your data, then records what it did.

Common uses:

  • Failure triage on new events
  • Rule-based events on ingest
  • Checking for missing topics or schema regressions after import
  • Adding recording context to tickets through external MCP servers
  • Opening a review layout and capturing screenshots as evidence
  • Summarizing sessions for standups or handoffs
  • Scheduled fleet-health summaries
  • Finding scenarios for datasets

Automations belong to a Project. To create one and read an automation run, see Get started with Automations.

note

Automations is available on Foxglove Cloud and Foxglove Cloud, bring your own storage (BYOS). It is not available for on-premises Primary Sites. Contact Foxglove if Automations isn't enabled for your organization yet.

Concepts​

  • Automation. A named prompt saved on a project. The prompt applies to every automation run.
  • Trigger. The condition that starts an automation run without someone clicking Run. Choose Manual to run the automation only when you start it.
  • Automation run. One firing. It takes the saved prompt and a separate Context for this firing, such as recording IDs or extra instructions, and has an agent do the work. Context doesn't change the saved prompt. For a triggered run, Foxglove fills Context with the event, recording, or session that fired the trigger. For a scheduled run, Context contains the cadence, scheduled UTC time, and project ID.
  • Output. What the automation run produced. An automation run can finish with no output.

Triggers​

You can start an automation run yourself. You can also attach one trigger so Foxglove starts the automation run when something happens in the project. Choose Manual to run the automation only when someone clicks Run.

Trigger can be:

  • Manual. The automation runs only when someone starts it.
  • On a schedule. Repeat every hour, day, week, or month. Hourly runs start at the top of the hour. Other schedules use a whole-hour UTC time; monthly dates are limited to days 1–28. Runs delayed by five minutes or more are skipped.
  • Event is created or Event is updated. Event type limits the trigger to one event type, or Any event type.
  • Recording is created. For a direct upload this happens as the recording finishes importing. Otherwise it happens when an Edge Site or a device running Foxlet reports a new recording.
  • Recording is imported, when a recording finishes importing.
  • Session is created, when a new session is created. A session groups recordings from one device.

When an automation creates or updates events, those events can start other automations. An automation run can also start another automation directly. Direct starts and event triggers share a limit of 3 more runs after the first, and each run can start more than one run. Beyond that, the next trigger match is saved as a failed run, and a direct start past the limit is refused. Editing data yourself, or starting a run yourself, starts the chain again from the beginning.

Choose what triggers a run​

Keep runs focused so costs stay predictable:

  • Prefer Event is created with a specific Event type over running on every recording.
  • Chain automations with events: a first pass creates events, and a second automation on that event type does the deeper review.
  • Use On a schedule for summaries instead of per-recording runs.

What a run can access​

An automation run uses the automation owner's project access and AI usage. It follows the saved prompt. When it can open the recording in Context, it can create and change events without asking for approval. It can start another automation in the same project without asking for approval; that run acts as the owner of the automation it starts and uses that owner's project access and AI usage.

Only the owner can edit the automation, including which MCP servers it may call. Project members who can open it can start a run and read the run. For MCP access choices, see External MCP accounts and services. The owner or an org admin can enable or disable the automation, remove its trigger, or delete it.

Run limits​

Each automation can run 1000 times per UTC calendar month. An organization can have 80 runs pending or running at once; one owner's automations can have 40. Triggered and scheduled runs wait when those concurrency limits are full. A run that waits a full day for a free slot, or that does not start within 60 minutes after it gets a slot, is marked failed.

A run can work for up to 58 minutes. It also stops if it reaches its estimated AI cost limit, or if the owner reaches their AI usage limit while it is working.

Models and billing​

Each automation has a Model setting: Auto, Claude Sonnet 5.5, or Claude Opus 5.5. That model is used for every run. When an automation has no model of its own, it uses the organization's default. The automation run page shows which model that run used.

Automation runs are billed as AI usage to the automation owner's organization. Usage is Anthropic token cost, plus a Foxglove fee of $1.00 per million tokens. See Pricing for included usage and overage.

A run has an estimated AI cost limit of about $50, including provider cost and the Foxglove fee. A model call already in progress can take the cost over that limit before its usage is reported.

When the owner reaches their AI usage limit, a running automation stops, and further runs that need that owner's usage are refused until usage renews or the organization adds capacity.

Webhooks​

Subscribe to automation_run.finished to hear when an automation run finishes. A completed delivery means the run finished, not that the task succeeded. The payload reports whether the run succeeded or failed. See Webhooks for setup and delivery guarantees.