Invocations

An invocation is a single run of a flow. It starts when something triggers the flow, and it groups together every event produced while that trigger is being processed, across all the blocks it reaches. Invocations are how Spacelift Flows measures how often your flows run, so this page explains precisely what is and is not counted.

Invocations and Events

Flows are event-driven. A block receives an event on one of its inputs, does its work, and emits one or more new events on its outputs. Each emitted event remembers the event it was produced from (its predecessor), which is how event data accumulates through a flow.

An invocation is defined by this lineage:

• An event that has no predecessor starts a new invocation. These are the trigger events of your flow, for example an incoming HTTP request or a schedule firing.
• Every event that descends from that trigger event, no matter how many blocks deep, belongs to the same invocation.

In other words, one trigger equals one invocation, regardless of how many blocks the flow contains or how many events are produced along the way.

HTTP Endpoint request  ───▶  Transform  ───▶  Condition  ──▶  Slack message
       (trigger event)         (event)          (event)          (event)
└──────────────────────── one invocation, four events ────────────────────────┘

Invocations are not events

Invocations and events are counted separately and used for different things. Invocations measure how many times your flows are triggered. Events measure how much processing happens and are the unit of the event limits. A single invocation of a large flow may produce dozens of events.

What Starts an Invocation

Any block that emits an event without a predecessor starts a new invocation. In practice, this happens in the following situations.

Trigger blocks

Trigger	When an invocation starts
HTTP Endpoint	Every accepted request. Requests that do not match a path, use a disallowed method, or target a disabled flow or block are rejected before any event is created and do not count.
Schedule	Every time the schedule fires. Schedules on disabled flows or blocks do not emit events and do not count.
MCP Tool	Every tool call made by an AI agent through your flow's MCP server.
Form Opened	Every time a user opens a form, for example from the Service Catalog.
Spacelift Deploy subscription blocks	Every matching run event or notification received from your Spacelift Deploy account.
App blocks	Every event an app block emits outside of processing an incoming event, for example from a webhook, a timer, an HTTP callback, or a lifecycle handler such as onSync, unless the app explicitly attaches it to a parent event. See event parentage.

Manual triggers

You can also start invocations yourself from the canvas:

• Sending a debug event to a block's input socket (see Block Management) starts a new invocation. It appears in the invocations list as Triggered manually.
• Re-emitting an event from a block's output starts a new invocation, even though the original event had a predecessor. Re-emitting is treated as a fresh run: the new event copies the original's data and is linked to it for history purposes, but it is counted as a separate invocation.

The same applies when these actions are performed through the AI assistant or the Flows MCP server.

Blocks that can start an invocation mid-flow

Two core blocks may start a new invocation even though they sit in the middle of a flow. This is expected behaviour, but it is easy to miss when reading invocation counts:

• Collect with a delay. When a group is emitted because its delay elapsed, the emitted event has no direct predecessor and starts a new invocation. The collected events are linked to it as secondary parents for history purposes only. Downstream blocks cannot reference upstream blocks through outputs as they normally would; the collected data is available only in the Collect block's items output. When a group is emitted because its count was reached, the emitted event joins the invocation of the event that completed the group, and outputs reflects that event.
• Handle Error without an originating event. When the error being handled happened while processing an event, the error event joins that event's invocation. When it did not, for example an app block's timer, HTTP callback, or internal message handler failed, the error event has no predecessor and starts a new invocation, shown as triggered from the Handle Error block.

Invocation Status

Every invocation has a status that summarizes the state of every block input that received one of its events. The status is recalculated shortly after any of those inputs changes state, so it may lag the canvas by a moment.

Status	Meaning
In progress	At least one block is still processing an event from this invocation, and nothing has failed.
Failed in progress	At least one block failed, and at least one block is still processing.
Processed	Every block finished and none failed. Events ignored by disabled blocks count as finished.
Failed	Every block finished and at least one failed. Failures handled by a Handle Error block still count here.

An invocation stays In progress for as long as any block is waiting: a Sleep block counting down, a Show Form block waiting for a submission, an app block waiting for an external approval. Long-running invocations are normal and are kept until they finish.

Processed and Failed are terminal statuses. A terminal invocation can become active again if you retry one of its failed events.

Viewing Invocations

On the flow canvas

The Invocations sidebar on the right of the canvas lists the invocations of the current flow, newest first, and refreshes automatically while any of them is in progress. Each card shows:

• when the invocation was triggered,
• its status,
• the block that triggered it, or Triggered manually for debug events. If the triggering block has since been deleted, the card says so.

Above the list, a bar shows the total number of invocations matching the current filters and how many of them contain errors. You can:

• Search by the name of the triggering block.
• Filter by status, by when the invocation was created, and by when it was last updated.
• Select an invocation to filter the canvas. The event counters on each block's sockets then show only events from that invocation, which is the quickest way to trace a single run through a complex flow. The live events control in the canvas toolbar shows which invocation is selected and lets you clear the selection.
• Open the event history using the clock icon on the card, which shows the full tree of events produced by the invocation starting from the trigger event.

In the flows list

The flows list in a project shows when each flow was last invoked and can be sorted by it.

On the dashboard

The organization Dashboard aggregates invocations across the projects you have access to:

• The Total invocations card and the Invocations over time chart on the overview tab, broken down by project, with hourly or daily granularity depending on the selected time range.
• The Invocations tab lists invocation counts per flow for the selected time range.

Dashboard counts are recorded when the invocation is triggered and are attributed to the project the flow belonged to at that moment. They are kept even when the flow is later deleted or moved to another project. Deleted flows appear struck through in the Invocations tab.

Retention

Invocation history is kept for 60 days after an invocation reaches a terminal status. After that, the invocation, its events, and their payloads are deleted. Invocations that are still in progress are kept regardless of age. Dashboard invocation counts are aggregated separately and are not affected by this retention.