> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/project-management/circleci/data-overview.md).

# Data Overview

CircleCI exposes data across your entire CI/CD pipeline — from high-level project and pipeline records down to individual job runs and branch-level performance insights. Here's what you can access through Coupler.io.

## Available entities

| Entity              | What it contains                                          |
| ------------------- | --------------------------------------------------------- |
| Pipelines           | Trigger source, status, creation time, VCS metadata       |
| Workflows           | Workflow name, status, duration, pipeline association     |
| Jobs                | Job name, number, status, start/stop times, executor type |
| Workflow jobs       | Jobs scoped to a specific workflow run                    |
| Insights metrics    | Success rate, throughput, mean duration, p95 duration     |
| Insights branches   | Per-branch pipeline metrics and failure counts            |
| Projects            | Project name, slug, VCS type, organization                |
| Specific projects   | Extended project details for a targeted project ID        |
| Contexts            | Context name, created date, environment variable keys     |
| Self IDs            | Authenticated user ID and external identifiers            |
| Self collaborations | Orgs and projects the user collaborates on                |
| Mes                 | User profile, login, analytics tracking ID                |

## Metrics and dimensions

#### Pipeline metrics

| Field         | Type      | Description                                       |
| ------------- | --------- | ------------------------------------------------- |
| id            | String    | Unique pipeline identifier                        |
| state         | String    | Pipeline state (created, errored, etc.)           |
| number        | Integer   | Sequential pipeline number                        |
| created\_at   | Timestamp | When the pipeline was triggered                   |
| trigger\_type | String    | What triggered the pipeline (push, API, schedule) |
| vcs\_branch   | String    | Branch that triggered the pipeline                |
| vcs\_revision | String    | Commit SHA                                        |

#### Workflow metrics

| Field         | Type      | Description                                 |
| ------------- | --------- | ------------------------------------------- |
| id            | String    | Unique workflow identifier                  |
| name          | String    | Workflow name                               |
| status        | String    | Status (success, failed, running, on\_hold) |
| created\_at   | Timestamp | Workflow start time                         |
| stopped\_at   | Timestamp | Workflow end time                           |
| pipeline\_id  | String    | Parent pipeline ID                          |
| project\_slug | String    | Associated project                          |

#### Job metrics

| Field          | Type      | Description                            |
| -------------- | --------- | -------------------------------------- |
| job\_number    | Integer   | Job number within the project          |
| name           | String    | Job name                               |
| status         | String    | Job status (success, failed, canceled) |
| started\_at    | Timestamp | Job start time                         |
| stopped\_at    | Timestamp | Job completion time                    |
| executor\_type | String    | Executor (docker, machine, macos)      |
| dependencies   | Array     | Upstream job dependencies              |

#### Insights metrics

| Field                 | Type    | Description                            |
| --------------------- | ------- | -------------------------------------- |
| success\_rate         | Float   | Percentage of successful pipeline runs |
| throughput            | Float   | Average number of runs per day         |
| mean\_duration\_sec   | Integer | Average run duration in seconds        |
| median\_duration\_sec | Integer | Median run duration                    |
| p95\_duration\_sec    | Integer | 95th percentile duration               |
| total\_runs           | Integer | Total number of runs in the period     |
| failed\_runs          | Integer | Count of failed runs                   |

#### Insights branches

| Field               | Type    | Description                        |
| ------------------- | ------- | ---------------------------------- |
| branch              | String  | Branch name                        |
| success\_rate       | Float   | Success rate for this branch       |
| total\_runs         | Integer | Total pipeline runs on this branch |
| mean\_duration\_sec | Integer | Average duration for this branch   |

## Common metric combinations

* **Workflow + Jobs** — join on `workflow_id` to see which jobs are dragging down workflow duration
* **Pipelines + Insights metrics** — combine to correlate pipeline volume with success rate trends
* **Insights branches + Projects** — spot which branches and projects are failing most often
* **Jobs + Workflows** — use Aggregate to calculate average job duration grouped by workflow name

## Use cases by role

{% tabs %}
{% tab title="Engineering managers" %}

* Track deployment frequency and change failure rate across teams
* Monitor pipeline success rates over time to measure CI/CD stability
* Compare workflow duration trends before and after infrastructure changes
* Use Insights metrics to build a DORA-style dashboard in Looker Studio or BigQuery
  {% endtab %}

{% tab title="DevOps / Platform teams" %}

* Identify the slowest jobs using p95 duration data and target them for optimization
* Analyze executor usage across jobs to right-size compute resources
* Pull context data to audit which environment variables are defined per context
* Use Append transformation to combine pipeline data from multiple projects into one report
  {% endtab %}

{% tab title="Development teams" %}

* Review branch-level insights to see which feature branches have the highest failure rates
* Track job failure patterns to catch flaky tests early
* Send pipeline status data to ChatGPT or Claude to auto-generate weekly CI health summaries
  {% endtab %}
  {% endtabs %}

## Platform-specific notes

* **Project ID vs. project slug** — some entities require a `project_id` (UUID from project settings), while others use a `project_slug` (e.g., `gh/myorg/myrepo`). Check the entity's parameter field carefully.
* **Workflow IDs** — you can supply multiple workflow IDs (one per line) to pull data for several workflows in the same data flow source.
* **Job number auto-fetch** — if you don't specify a job number, Coupler.io will auto-fetch it from Workflow jobs, so you only need to set this manually for specific targeted pulls.
* **Start date filtering** — the start date applies to pipeline-based entities. Insights entities have their own aggregation window on the CircleCI side.
* **Rate limits** — CircleCI's API is rate-limited; very large orgs with many pipelines may see slower syncs on first historical load.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coupler.io/sources/category/project-management/circleci/data-overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.