canonical: https://jentic.com/apis/chronosphere.io/chronosphere

# Chronosphere API

Jentic publishes the only available OpenAPI specification for Chronosphere API, keeping it validated and agent-ready. Chronosphere is a cloud-native observability platform built on M3 and OpenTelemetry that ingests metrics, logs, and traces at scale. The API enables programmatic management of observability configurations - collections that group related telemetry, monitors that fire alerts on metric thresholds, and PromQL-style metric queries against the time-series store. It is used by platform and SRE teams who manage observability as code rather than through the UI.

## For AI agents

Manage Chronosphere observability configuration - list and create collections, list monitors, and execute PromQL metric queries.

## Scope

Does not handle log ingestion, trace storage management, or on-call paging - use for metric queries and monitor or collection configuration only.

## Capabilities

- List existing telemetry collections via `/api/v1/config/collections`
- Create a new collection that groups related metrics through POST `/api/v1/config/collections`
- List all configured alert monitors via `/api/v1/config/monitors`
- Execute PromQL metric queries against the time-series store via `/data/metrics/api/v1/query`
- Manage observability configuration as code rather than through the Chronosphere UI

## Use cases

### Observability as Code

Platform teams manage Chronosphere collections and monitors through Terraform or in-house tooling rather than clicking through the UI. The `/api/v1/config/collections` endpoint supports both list and create, allowing automated provisioning of telemetry groupings as new services come online. This keeps observability configuration in version control alongside the applications it monitors.

Example prompt: POST a new collection to `/api/v1/config/collections` named 'checkout-service' with the appropriate labels and verify it appears in a follow-up GET

### Scheduled Metric Queries for Reports

SRE teams run scheduled PromQL queries to populate weekly reliability reports - error rates, latency percentiles, saturation metrics. The `/data/metrics/api/v1/query` endpoint accepts a PromQL expression and returns the time-series result, which a reporting job then formats into stakeholder-friendly summaries without anyone needing to log into Chronosphere.

Example prompt: Execute the PromQL query 'rate(http_requests_total{job="checkout"}[5m])' against `/data/metrics/api/v1/query` and return the result

### Monitor Inventory Audit

Large organisations accumulate hundreds of alert monitors that drift over time - duplicates, monitors on deprecated services, monitors with stale thresholds. The `/api/v1/config/monitors` endpoint lists every configured monitor so an audit job can flag duplicates, monitors without owners, or monitors that have not fired in months for cleanup.

Example prompt: List all monitors via `/api/v1/config/monitors` and produce a report of monitors lacking an owner label

### Agent-Driven Incident Triage

An AI agent helping an on-call engineer triage an incident calls Chronosphere through Jentic to query the current value of relevant metrics and check which monitors are firing. The agent searches Jentic for 'query a metric in Chronosphere', loads the query operation, and runs the relevant PromQL expressions to surface a focused incident summary.

Example prompt: Search Jentic for 'query a metric in Chronosphere', load `/data/metrics/api/v1/query`, and run three PromQL expressions for current latency, error rate, and saturation

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/api/v1/config/collections` | List all collections |
| POST | `/api/v1/config/collections` | Create a new collection |
| GET | `/api/v1/config/monitors` | List all monitors |
| GET | `/data/metrics/api/v1/query` | Execute a PromQL metric query |

## Key resources

- **Collections** — Logical groupings of related metrics and telemetry
- **Monitors** — Alert definitions that fire on metric thresholds
- **Metrics** — PromQL query interface to the time-series store

## Why Jentic

- **Setup:** Wiring Chronosphere by hand means handling its apiToken header and building the tenant-specific host into the base URL for metric queries and config yourself. Through Jentic you install once, import the Chronosphere API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Chronosphere routes by tenant host and takes config details in the request body rather than a resource id in the URL path, so scope the agent to the operations it needs, such as querying metrics and reading monitors. You choose that set, so creating collections is not included unless you add it.
- **Credential handling:** Your Chronosphere apiToken and tenant identifier are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'query a metric in Chronosphere' or 'list monitors', and Jentic returns the matching operation with its input schema and tenant binding so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **New Relic** — Full-stack observability platform with metrics, logs, traces, and APM
- **PagerDuty** — Incident response and on-call paging, often paired with observability platforms
- **Sentry** — Application error monitoring with stack traces and release tracking

## FAQ

### Why is there no official OpenAPI spec for Chronosphere API?

Chronosphere does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Chronosphere API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Chronosphere API use?

Chronosphere uses an API token passed in the apiToken header. The base URL is tenant-specific (https://{tenant}.chronosphere.io) so both the token and the tenant name need to be configured. Through Jentic, the token is stored encrypted in the vault and the agent receives a scoped reference.

### Can I run PromQL queries through the Chronosphere API?

Yes. The `/data/metrics/api/v1/query` endpoint accepts a PromQL expression and returns the matching time-series result, which is the standard pattern for querying metrics programmatically without using the Chronosphere UI.

### Can I create collections programmatically?

Yes. The POST `/api/v1/config/collections` endpoint creates a new collection with the supplied labels and configuration, which lets platform teams provision observability groupings as part of service onboarding scripts or Terraform pipelines.

### What are the rate limits for the Chronosphere API?

Specific rate limits are not declared in the OpenAPI spec - Chronosphere applies tenant-level throttling. Plan to backoff on 429 responses and avoid tight polling against `/data/metrics/api/v1/query` for high-cardinality expressions.

### How do I run a PromQL query through Jentic?

Run pip install jentic, search for 'query a metric in Chronosphere', load the `/data/metrics/api/v1/query` operation, and execute with the PromQL expression as the query parameter. Jentic injects the apiToken header and the tenant from the vault.

### Can I limit what my agent is allowed to do with the Chronosphere API?

Yes. Jentic One runs self-hosted, so your own rules decide which Chronosphere operations and credentials the agent may use. You can allow read-only calls like querying PromQL metrics via `/data/metrics/api/v1/query` and listing monitors and collections, while withholding the create-collection operation on POST `/api/v1/config/collections.` Because Chronosphere routes by tenant host and takes config in the request body rather than a resource id in the URL, you scope the agent to exactly the operation set it needs.