Get an app's request and cost breakdown over time
How much traffic an app served and what it cost to run, over a chosen period. Requests are counted per time bucket and split by response status (2xx/4xx/5xx, normal and error WebSocket closes, and anything else); cost is split across GPU, CPU and memory. Every bucket in the period is returned, zero-filled where there was no activity, so the series can be charted without gap handling.
Authorizations
Service Account Token authentication. To authenticate API requests:
-
Create a Service Account Token:
- Go to the Cerebrium Dashboard and open the API Keys page
- Click Create Service Account, name it (e.g., "GitHub Actions CI/CD"), choose an expiry date, and click Create
- Copy the token generated for the desired service account
-
Use the Token: Include the service account token in the Authorization header of API requests:
Authorization: Bearer <your-service-account-token> -
Best Practices:
- Create separate service accounts for different environments (dev, staging, prod)
- Store tokens securely as secrets in consuming applications or workflows
- Set appropriate expiry dates and rotate tokens regularly
- Never commit tokens to source control
For CI/CD integration examples, see the CI/CD documentation.
Query Parameters
Report on a whole billing month, in UTC. One of current or previous; defaults to current. Ignored when start and end are supplied. A billing month is longer than the minute and hour intervals allow, so those require start and end.
Start of an arbitrary period, RFC3339. Takes precedence over month, and must be sent with end. Cannot be more than 180 days ago.
End of an arbitrary period, RFC3339. Takes precedence over month, and must be sent with start.
Bucket size to group the series by: minute, hour, day (default) or month. Each caps how long a period you can ask for — 6 hours for minute, 7 days for hour, 180 days for day and month — and a longer one is rejected with a 400. Because a billing month is longer than the minute and hour caps, those intervals must be paired with start and end rather than month.
IANA timezone the buckets fall in, e.g. America/New_York. Defaults to UTC. Month and day buckets start at midnight in this zone, and minute and hour buckets on its minute or hour — which is not the UTC hour in zones offset by 30 or 45 minutes, such as Asia/Kolkata.
Response
Two zero-filled time series covering the whole period — requests by response status and cost by resource — plus a total for each. Both series are objects keyed by bucket start, in ascending key order.
Spend for the whole period, same fields as a costs entry. Equal to the sum of the buckets.
Spend per bucket in fractional cents, split into gpu_cost_cents, cpu_cost_cents and memory_cost_cents alongside total_cost_cents, with total_running_time_ms for the container time that spend covers. Note the key format differs from requests: month and day buckets are keyed YYYY-MM-DD (a month by its first day), minute and hour buckets RFC3339. unique_container_count is not populated.
End of the period actually reported on, RFC3339. Echoes end, or the last moment of the billing month when month was used.
Bucket size the series were grouped by, echoing the interval requested: minute, hour, day or month.
Request counts for the whole period, same fields as a requests entry. Equal to the sum of the buckets.
Request counts per bucket, keyed by bucket start in RFC3339. Month and day buckets fall at midnight in tz; minute and hour buckets are instants expressed in UTC. Each value splits total into 2xx, 4xx, 5xx, websocket_success (close codes 1000-1001), websocket_error (1002-1999), and other (anything outside those ranges, including no status).
Start of the period actually reported on, RFC3339. Echoes start, or the first moment of the billing month when month was used.