Get Bucket Metric History
const url = 'https://example.com/storage/v1/workspaces/example/engines/example/buckets:metricHistory?metric=STORAGE_METRIC_UNSPECIFIED';const options = {method: 'GET'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url 'https://example.com/storage/v1/workspaces/example/engines/example/buckets:metricHistory?metric=STORAGE_METRIC_UNSPECIFIED'Returns one metric’s exact per-month series over an inclusive billing-period range, so the
console can chart month-over-month trend for any KPI card. Each point is tri-state: a real
value, or NO_DATA_YET for a month with no recorded data (never a fabricated zero). With a
concrete provider the series covers that provider; with - it federates across all providers.
Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”The workspace to draw the metric history for
The cloud provider to draw the history over: qibdo, aws, gcp, azure, or ’-’ for all providers
Query Parameters
Section titled “Query Parameters ”The metric to draw the history for
Four-digit calendar year (e.g. 2026). Floored at the Unix epoch year and capped at a plausible upper bound: an unbounded year lets a caller-supplied period range expand to billions of months before any query runs. The range’s own span cap is the primary bound; this keeps the ordinal arithmetic in a sane domain.
Calendar month, 1 (January) through 12 (December).
Four-digit calendar year (e.g. 2026). Floored at the Unix epoch year and capped at a plausible upper bound: an unbounded year lets a caller-supplied period range expand to billions of months before any query runs. The range’s own span cap is the primary bound; this keeps the ordinal arithmetic in a sane domain.
Calendar month, 1 (January) through 12 (December).
Responses
Section titled “ Responses ”OK
Get Bucket Metric History Response
The metric’s per-month series, one point per billing month in the requested inclusive range.
object
The per-month series, ordered oldest to newest. Bounded by the request’s 36-month maximum span, so the series is a server-bounded result set rather than an open collection — it carries no AIP-158 List fields, for the same reason ListStatDescriptors does not (ADR qib-522/0001).
Metric Series Point
One month of a metric history: the billing period plus the metric’s tri-state value. Every point in a series carries the same value arm (fixed by the requested metric); a month with no recorded data reports NO_DATA_YET rather than a fabricated zero.
object
The billing month this point covers.
object
Four-digit calendar year (e.g. 2026). Floored at the Unix epoch year and capped at a plausible upper bound: an unbounded year lets a caller-supplied period range expand to billions of months before any query runs. The range’s own span cap is the primary bound; this keeps the ordinal arithmetic in a sane domain.
Calendar month, 1 (January) through 12 (December).
A count-valued metric (operations, object count, bucket count).
object
The measured value. Only meaningful when availability is AVAILABLE.
A size-valued metric in bytes (egress, stored size).
object
The measured value. Only meaningful when availability is AVAILABLE.
A money-valued metric (spend).
object
The measured amount. Only meaningful when availability is AVAILABLE.
object
The three-letter currency code defined in ISO 4217.
The whole units of the amount.
For example if currencyCode is "USD", then 1 unit is one US dollar.
Number of nano (10^-9) units of the amount.
The value must be between -999,999,999 and +999,999,999 inclusive.
If units is positive, nanos must be positive or zero.
If units is zero, nanos can be positive, zero, or negative.
If units is negative, nanos must be negative or zero.
For example $-1.75 is represented as units=-1 and nanos=-750,000,000.
Example
{ "points": [ { "count": { "availability": "STAT_AVAILABILITY_UNSPECIFIED" }, "size_bytes": { "availability": "STAT_AVAILABILITY_UNSPECIFIED" }, "money": { "availability": "STAT_AVAILABILITY_UNSPECIFIED" } } ]}default
Section titled “default ”Default error response
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
object
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
A list of messages that carry the error details. There is a common set of message types for APIs to use.
Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.
object
The type of the serialized message.
Example generated
{ "code": 1, "message": "example", "details": [ { "@type": "example" } ]}