d0fc0114da66
Query execution seconds
Retrieve total execution time for an active workspace, aggregated into time buckets. The total_execution_seconds field sums (end_time - start_time) across every completed run whose start_time falls within the bucket. In-flight runs (without a recorded end_time) are excluded both from this sum and from the total_test_runs count on this endpoint — consult testRunCounts if you want a count that includes in-flight runs.
Execution time is measured from the moment a run starts executing to the moment it completes (successfully or otherwise). It does not include time spent queued waiting for a runner. Useful for billing, capacity planning, or attributing compute cost to a specific team (via application_id or plan_id), test type, or time window.
All filter, granularity, and group_by semantics are identical to the testRunCounts endpoint. All timestamps are Unix epoch milliseconds, and bucket boundaries are aligned to UTC.
Path parameters
The workspace ID
Query parameters
Inclusive start of the time range to report on, as Unix epoch milliseconds. Must be strictly less than end_time.
Exclusive end of the time range to report on, as Unix epoch milliseconds. Must be strictly greater than start_time. The total window end_time - start_time is capped by granularity: 90 days for daily, 400 days for weekly or monthly. Requests exceeding the cap return HTTP 400.
Time bucket size for the response. Valid values are daily, weekly, and monthly. Daily buckets start at midnight UTC. Weekly buckets follow ISO-8601 week boundaries (Monday 00:00 UTC). Monthly buckets align with the first day of each calendar month at 00:00 UTC.
Optional dimension to break the response down by. Without group_by, each time bucket aggregates all matching runs. With group_by set, each time bucket is further split by the grouping value and the group_id field on each bucket identifies which plan, application, or workspace it represents (workspace only appears on account-level endpoints). Buckets are emitted for every (period, group_id) combination that has at least one matching run; combinations with zero runs are omitted.
Filter results to runs associated with a specific mabl application. Only runs whose application_id matches this value exactly are included. Combined additively with other filters (plan_id, test_type) — runs must match all provided filters.
Filter results to runs that were part of executions of a specific test plan. Useful for attributing usage to a particular CI pipeline, schedule, or deployment trigger. Runs not associated with any plan (for example, ad-hoc runs from the Trainer) are excluded when this filter is set.
Filter results to runs of a specific test type. Valid values are browser (UI automation), api (REST API tests), mobile, and performance. Useful when a workspace exercises multiple test types and you want to report on them independently — for example, to split UI-automation usage from API-test usage in an attribution dashboard. When omitted, all test types are included.
Response
Execution time grouped by time buckets