> ## Documentation Index
> Fetch the complete documentation index at: https://docs.failpath.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# How Failpath Monitors Your Backend Flows and Steps

> Failpath is a flow monitoring tool that tracks every step in your backend workflows, giving you real-time visibility into successes, failures, and skips.

Failpath is a flow monitoring tool that tracks every step of your backend workflows in real time. Instead of digging through logs after something goes wrong, you get a live view of each run on the Failpath dashboard — showing which steps succeeded, which failed, and which were skipped, along with the exact point of failure and any attached metadata.

## How Failpath works

Failpath is built around two packages that work together. The **CLI** (`failpath`) manages flow graphs: you run `npx failpath init` once to connect your repository to a Failpath project, which writes your dashboard's current flow definition to `.failpath/flows.json` and generates `.failpath/sdk.ts` for typed flow-key autocomplete. From there, `npx failpath publish` pushes local edits to the dashboard and regenerates the typed helper, while `npx failpath sync` pulls dashboard changes back into your repo and regenerates it too.

The **SDK** (`@failpath/sdk`) handles runtime instrumentation. You usually import `createTypedFailpathClient` and `failpathFlows` from `.failpath/sdk.ts`, then call `run()` to start a named flow run and `step()` around each logical unit of work. Every `step()` call queues a `running` event before the operation starts, then queues a `success` or `error` event when it finishes. If the wrapped function throws, the SDK records the error and rethrows the original exception so your application error handling stays intact.

Together, the CLI defines what your flows look like and the SDK reports what actually happened during each execution.

## Key concepts

* **Flows** — A named sequence of steps that represents one logical backend process, such as `checkout` or `send-invoice`. Flows are defined in `.failpath/flows.json`, typed in `.failpath/sdk.ts`, and managed with the CLI.
* **Runs** — A single execution of a flow, identified by a `runId` you supply (typically a request ID or job ID). Every step in the same request shares the same run.
* **Steps** — The individual units of work within a run, each identified by a `stepKey` that matches the `sdkStepKey` in your flow definition.
* **Events** — The status signals (`running`, `success`, `error`, `skipped`) that the SDK records as each step executes.

<CardGroup cols={2}>
  <Card title="Quick Start" icon="rocket" href="/quickstart">
    Initialize Failpath, instrument your first function, and publish a flow in under five minutes.
  </Card>

  <Card title="CLI Reference" icon="terminal" href="/cli/overview">
    Full reference for the `init`, `publish`, and `sync` commands.
  </Card>

  <Card title="SDK Reference" icon="code" href="/sdk/overview">
    Explore typed keys, client options, `run()`, `step()`, and testing helpers.
  </Card>

  <Card title="Core Concepts" icon="book-open" href="/concepts/flows">
    Dive deeper into flows, runs, steps, and how they map to your application code.
  </Card>
</CardGroup>
