---
title: "Query account test run counts"
method: GET
path: "/accounts/{account_id}/reports/usage/testRunCounts"
tags: ["Reporting"]
---

# Query account test run counts

`GET /accounts/{account_id}/reports/usage/testRunCounts`

Same as `/workspaces/{workspace_id}/reports/usage/testRunCounts` but aggregates across every active workspace the authenticated caller has access to within the account. Use this endpoint for account-wide usage dashboards where you want a single aggregated bucket per time period, or pair it with `group_by=workspace` to produce a per-workspace breakdown of test run counts.

To scope the query to a single workspace within the account (for example, to reuse the same account-level API key while drilling into one workspace), pass its identifier as the `workspace_id` query parameter. When `workspace_id` is provided, the caller must still have access to that workspace.

All filter (`application_id`, `plan_id`, `test_type`), granularity, `group_by`, and time-range rules are identical to the workspace-level endpoint. All timestamps are Unix epoch milliseconds.

## Path parameters

- `account_id` string, required

## Query parameters

- `start_time` integer, required
- `end_time` integer, required
- `granularity` 'daily' | 'weekly' | 'monthly', required
- `group_by` 'workspace' | 'plan' | 'application'
- `application_id` string
- `plan_id` string
- `test_type` 'api' | 'browser' | 'mobile' | 'performance'
- `workspace_id` string

## Response `200`

Test run counts grouped by time buckets

- UsageTestRunCountsResponse — Response payload for the test run counts endpoint. Contains the resolved query range, the granularity and `group_by` dimension that were applied, and one entry in `time_buckets` per (time period, group_id) combination.
  - `start_time` integer — Inclusive start of the queried time range as Unix epoch milliseconds, echoed from the request.
  - `end_time` integer — Exclusive end of the queried time range as Unix epoch milliseconds, echoed from the request.
  - `granularity` 'daily' | 'weekly' | 'monthly' — Time bucket size used for grouping test run results. `daily` aligns buckets to midnight UTC. `weekly` aligns to Monday 00:00 UTC of each ISO-8601 week. `monthly` aligns to the first day of each calendar month at 00:00 UTC.
  - `group_by` 'workspace' | 'plan' | 'application' — Dimension applied to break usage report results down by. `plan` emits one bucket per (time period, plan_id); `application` emits one bucket per (time period, application_id); `workspace` emits one bucket per (time period, workspace_id) and only appears on account-level responses.
  - `time_buckets` UsageTestRunCountBucket[] — Time-bucketed count results. Ordered by `bucket_start_time` ascending, then by `group_id` ascending when `group_by` is set. Buckets with zero matching runs are omitted — if you expect a continuous series, fill gaps on the consumer side using the request `start_time`/`end_time` and `granularity`.
    - `bucket_start_time` integer — Inclusive start of the time bucket as Unix epoch milliseconds. Aligned to midnight UTC, Monday 00:00 UTC, or first-of-month 00:00 UTC per the selected granularity.
    - `bucket_end_time` integer — Exclusive end of the time bucket as Unix epoch milliseconds. Equal to the `bucket_start_time` of the following period for that bucket size.
    - `group_id` string — ID of the grouping dimension value. Only present when the request specifies `group_by`; omitted otherwise. The value is a plan ID when `group_by=plan`, an application ID when `group_by=application`, or a workspace ID when `group_by=workspace` (account-level endpoints only). Without `group_by` you get one bucket per time period; with `group_by` you get one bucket per (time period x dimension value), so consumers can break down counts or minutes by plan, application, or workspace.
    - `group_name` string — Human-readable name of the group corresponding to `group_id`. Populated on a best-effort basis — may be absent for deleted or otherwise unresolvable entities. Not guaranteed unique; use `group_id` for joins.
    - `total_test_runs` integer — Total number of test runs that started within this bucket and match all filters on the request. Includes runs that are still in flight (have started but not yet completed).
    - `passed_test_runs` integer — Subset of `total_test_runs` that completed successfully (status is `completed` and `success` is true). In-flight runs are excluded.
    - `failed_test_runs` integer — Subset of `total_test_runs` that did not pass — this covers runs that completed with `success: false`, runs that were terminated, and runs that are still in flight (counted as not-yet-passed). `passed_test_runs` plus `failed_test_runs` equals `total_test_runs`.

## Other responses

- `400` — Invalid or missing parameter
- `401` — User not authenticated
- `403` — User not authorized
- `default` — Unknown error

---

[API](https://skmtc.net/mabl/apis/mabl-api.md) · [All operations](https://skmtc.net/mabl/apis/mabl-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/mabl/mabl-api/revisions/d0fc0114da66/schema)