canonical: https://jentic.com/apis/algolia.com/algolia-monitoring-api

# Algolia Monitoring API

Jentic publishes the only available OpenAPI specification for the Algolia Monitoring API, keeping it validated and agent-ready. The Monitoring API exposes real-time and historical infrastructure metrics for Algolia clusters - latency, indexing time, reachability, and incident reports - sourced from external probes that hit Algolia's servers continuously. It is intended for status pages, on-call dashboards, and SLO reporting, not for app-specific performance debugging. Premium and Elevate plan customers can access cluster-level metrics; status and incident endpoints are public.

## For AI agents

Pull Algolia cluster status, latency, indexing time, and incident data so agents can monitor service health and trigger alerts. Read-only.

## Scope

Does not handle search execution, index management, or app-level analytics - use the Algolia Search and Insights APIs for those. Use this API for cluster health and infrastructure monitoring only.

## Capabilities

- Check the operational status of Algolia clusters via /1/status and /1/status/{clusters}
- Retrieve current and historical incidents per cluster via /1/incidents and /1/incidents/{clusters}
- Query latency metrics for any cluster the application is on via /1/latency/{clusters}
- Read indexing time metrics to detect ingestion slowdowns via /1/indexing/{clusters}
- Inspect reachability probe results from multiple geographic regions via /1/reachability/{clusters}/probes
- Pull infrastructure metrics like CPU, RAM, and SSD usage for premium-tier accounts via /1/infrastructure/{metric}/period/{period}

## Use cases

### Internal status page driven by Algolia metrics

Build an internal status page that polls /1/status and /1/incidents on a schedule and surfaces any open incidents alongside latency from /1/latency. Because /1/status and /1/incidents do not require auth, the polling job can be a cheap unauthenticated cron without managing API keys.

Example prompt: GET /1/status and /1/incidents every 60 seconds and post any non-operational state to the on-call Slack channel

### On-call latency alerting

Poll /1/latency/{clusters} every minute, compare the rolling p95 to a threshold, and page on-call when search latency degrades. Combined with /1/indexing/{clusters} this catches both query-side and ingestion-side slowdowns before users notice.

Example prompt: GET /1/latency/c1-prod every 60 seconds, raise a PagerDuty incident if p95 latency exceeds 200 ms for 3 consecutive samples

### Capacity planning for premium-tier accounts

On Premium and Elevate plans, query /1/infrastructure/{metric}/period/{period} for CPU, RAM, and SSD usage trends. Combine the data with /1/inventory/servers to see which servers are nearing saturation and decide whether to provision a larger cluster.

Example prompt: GET /1/infrastructure/cpu_usage/period/day and /1/inventory/servers to identify any server above 75 percent CPU

### Agent-driven health checks before high-stakes operations

Before triggering a large reindex or migration, an AI agent can call the Monitoring API through Jentic to verify cluster status and current latency. If the cluster shows incidents or elevated indexing time, the agent can pause the operation and notify a human.

Example prompt: Search Jentic for 'check Algolia cluster status', load getStatus, and execute - abort the reindex plan if any cluster reports degraded state

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /1/status | Get overall Algolia cluster status |
| GET | /1/incidents | List incidents across all clusters |
| GET | /1/latency/{clusters} | Latency metrics per cluster |
| GET | /1/indexing/{clusters} | Indexing time per cluster |
| GET | /1/reachability/{clusters}/probes | Reachability probe results |
| GET | /1/infrastructure/{metric}/period/{period} | Infrastructure metric over a time period |

## Key resources

- **Status** — Operational state of clusters and the Algolia infrastructure overall
- **Incidents** — Current and historical incidents grouped by cluster
- **Latency** — Search latency metrics per cluster
- **Indexing** — Indexing time metrics per cluster
- **Reachability** — Probe-based reachability checks from multiple regions
- **Infrastructure** — CPU, RAM, and SSD metrics for premium-tier accounts

## Why Jentic

- **Setup:** Wiring the Algolia Monitoring API by hand means sending its API key, targeting the status.algolia.com host, and polling cluster status, latency, and incident reads yourself. Through Jentic you install once, import the Algolia Monitoring API from the API Directory, store the API key once, and your agent calls it.
- **Permission scoping:** The Monitoring API puts the cluster and metric names in the URL path (/1/latency/{clusters}, /1/indexing/{clusters}, /1/infrastructure/{metric}/period/{period}), so a rule can pin your agent to one cluster or metric. This API is read-only, so you choose which of these health reads the agent may call.
- **Credential handling:** Your Algolia API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'check Algolia cluster status' or 'read cluster latency', and Jentic returns the matching Algolia Monitoring operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Statuspage API** — General-purpose status page hosting and incident communication
- **UptimeRobot API** — External uptime monitoring with HTTP and ping checks
- **Algolia Search API** — Run searches against the clusters Monitoring observes
- **New Relic API** — Application observability layered on top of infrastructure metrics

## FAQ

### Why is there no official OpenAPI spec for the Algolia Monitoring API?

Algolia does not publish a standalone OpenAPI specification for the Monitoring API. Jentic generates and maintains this spec so that AI agents and developers can call the Monitoring 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 Algolia Monitoring API use?

Infrastructure endpoints require X-Algolia-Application-Id and X-Algolia-API-Key headers and are limited to Premium and Elevate plans. Status and incidents endpoints are public and require no auth. Through Jentic, the Monitoring API key is stored in the vault and injected only when calling the protected endpoints.

### Can I get historical latency data with the Monitoring API?

Yes. /1/latency/{clusters} returns recent latency samples and /1/infrastructure/{metric}/period/{period} returns metrics aggregated over the requested period. Historical depth depends on plan tier.

### What are the rate limits for the Algolia Monitoring API?

The spec does not declare explicit rate limits. Algolia recommends polling intervals no faster than once per minute for /1/status and /1/latency to avoid throttling on large fleets.

### How do I monitor cluster status from an agent through Jentic?

Search Jentic for 'check Algolia cluster status', load the getStatus operation, and execute. For protected endpoints like /1/infrastructure, Jentic injects the Monitoring API key so the agent never handles it directly.

### Does this API show metrics specific to my application?

No. Metrics reflect the overall Algolia infrastructure status for the clusters your application sits on, not the performance of your specific app ID. Use the Search API analytics for app-level query metrics.

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

Yes. Because you run Jentic One yourself, your own rules decide which Monitoring operations and credentials the agent may use. The Algolia Monitoring API puts cluster and metric names directly in the URL path (/1/latency/{clusters}, /1/indexing/{clusters}, /1/infrastructure/{metric}/period/{period}), so a rule can pin the agent to a single cluster or metric. Since every operation is read-only, you simply choose which health reads such as status, incidents, latency, or infrastructure the agent is allowed to call.