Prometheus API for SLO time series
Query your Nobl9 SLO time series with PromQL through a Prometheus-compatible API.
Prometheus API for SLO time series
The Prometheus API for SLO time series
For the public metric schema, PromQL examples, query limits and freshness, and consumption guides (Grafana, SDKs, Go + nobl9-go), see the Prometheus API guide.
The Prometheus API for SLO time series is currently in Beta. The metric schema and the set of implemented endpoints can change while the feature is being finalized.
Base URL
Every endpoint is served under:
https://<your-nobl9-instance>/api/prometheus/v1/api/v1
For example, on the Nobl9 EU instance (app.nobl9.com):
https://app.nobl9.com/api/prometheus/v1/api/v1
On the US instance, use us1.nobl9.com in place of app.nobl9.com.
The path contains v1 twice on purpose:
- The first
v1(/api/prometheus/v1) is Nobl9's version of the integration. - The second
v1(/api/v1) is the Prometheus API version, governed by Prometheus.
Most Prometheus clients (Grafana, SDKs, the prometheus Go client) append the /api/v1 segment themselves. In those tools, set the server URL to https://<your-nobl9-instance>/api/prometheus/v1.
Data scope and access control
Queries return data only from the organization the access key belongs to. Within that organization, the standard Nobl9 RBAC rules apply, so the data you can query matches the SLOs you can see in the UI.
Rate limits
Requests are rate-limited per organization: an average of 50 requests per minute with a burst of up to 100. If you exceed the limit, requests are throttled — back off and retry. Keep automated consumers such as dashboards and scripts to reasonable refresh intervals, and prefer narrow, filtered queries over broad ones.
Query limits
Each /query and /query_range request is checked against the following budgets before it runs. A query that exceeds any of them is rejected with a 400 error describing which limit was hit.
| Limit | Default | What it bounds |
|---|---|---|
| Maximum series per query | 1,000 | Number of time series a query may select. |
| Maximum query time range | 8,760h (~1 year) | Span between start and end on range queries. |
| Maximum series × time | 87,600h (~10 years) | Selected series multiplied by the query time range. |
| Maximum result points | 5,256,000 | Total data points a query may produce (series × evaluation points). |
When you hit a limit, narrow the query with more specific label matchers (for example, add a project or slo filter), shorten the time range, or increase the step on range queries. The metadata endpoints (/series, /labels, /label/{label_name}/values, and /metadata) accept an optional limit parameter that caps the number of returned entries (0 means no limit); it does not apply to /query or /query_range.
Query freshness
The backend evaluates queries slightly behind real time (about 60 seconds), so the most recent data point may not yet be present in an instant query. Staleness is detected per series from the actual sample interval rather than using Prometheus' fixed five-minute lookback, so sparse series can appear to end sooner than they would in a standard Prometheus server.
Set the standard Prometheus lookback_delta URL parameter (a duration) on /query or /query_range to cap how far back a sample stays valid for an instant selector: a larger value keeps sparse or slow series visible longer, a smaller value enforces stricter freshness. For example, &lookback_delta=10m treats any sample within the last 10 minutes as current. When omitted, staleness is auto-detected per series.
How a time window is evaluated
A time window in brackets, such as [1h], doesn't read the samples stored in that window. Nobl9 resolves each metric name to an expression rather than to a single stored series, and a time window around an expression is evaluated as a subquery: the expression is re-evaluated at a fixed interval across the window, and the function receives those results instead of the stored samples.
That interval is the subquery's resolution. You can write it after a colon, as [<window>:<resolution>]. Omit it and the default is never the metric's own sample interval:
| Query | Default resolution |
|---|---|
| Range query | The step of the request. |
| Instant query | The query's lookback, five minutes by default. |
Because the instant default is the lookback, setting lookback_delta changes the resolution with it. Neither default follows the metric's own sample interval: a metric sampled once a minute and a pre-aggregated _1h variant both get a five-minute resolution.
Either default loses data. At a one-hour window with step=1h the expression is evaluated once, so avg_over_time(reliability{...}[1h]) averages a single value rather than the hour's 60 samples. Run the same expression as an instant query and the five-minute default gives it 12 values, whatever the metric's own sample interval. In Grafana this is what makes a number move: a panel is a range query whose step comes from the width of the panel, so the same panel reports a different number at a different dashboard time range.
To tie the result to your data rather than to the request, write the resolution yourself and match it to the sample interval of the metric. Nobl9 SLO metrics are sampled once a minute, so a one-hour window is [1h:1m]:
avg_over_time(reliability{project="my-project",slo="my-slo"}[1h:1m])
That averages 60 values on both kinds of query. Match the resolution to your own data rather than always writing 1m: over a long window a finer resolution costs more to evaluate, and a coarser one is a trade-off rather than an error, as [7d:1h] averages 168 values instead of 10,080 samples.
Authentication
- HTTP: Basic Auth
- HTTP: Bearer Auth
Authenticate requests with a Nobl9 access key over HTTP Basic auth.
Use the access key Client ID as the username and the Client Secret as the password, sending
Authorization: Basic base64(clientId:clientSecret).
To retrieve your access key credentials, go to the Nobl9 web application > Settings > My user access keys, or ask your organization admin for an API key.
Security Scheme Type: | http |
|---|---|
HTTP Authorization Scheme: | basic |
Authenticate requests with a Nobl9 access token over HTTP Bearer auth.
Include the token in the Authorization header as Bearer <token>.
Generate the token from your access key credentials through the access token endpoint.
Security Scheme Type: | http |
|---|---|
HTTP Authorization Scheme: | bearer |
Bearer format: | JWT |