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. Written ONLY when availability is AVAILABLE, so an unmeasured stat is never read as a real, measured zero.
object
The exact amount in major units, as a decimal string, for example 12.34, 100 or -0.05.
Up to 19 digits before the decimal point and up to 8 after it. Trailing zeros are removed, so
12.3400 is sent as 12.34. Some amounts are stored with fewer decimals than 8 and are
rounded when they are saved, so a value read back may be shorter than the one sent in.
The ISO-4217 currency code in uppercase, for example USD.
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" } ]}