Algolia Monitoring API

Name: Algolia Monitoring API
Brand: Algolia Monitoring API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring ObservabilityapiKey14 Endpoints

Install Jentic One Beta

Connect the Algolia Monitoring API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Algolia Monitoring API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Algolia Monitoring API.

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}

GET STARTED

Start building with Algolia Monitoring API

Explore with Jentic

View OpenAPI Document

For Agents

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

Use for: Check whether my Algolia cluster is currently up, Retrieve open incidents for a specific cluster, Get the average search latency for the past hour, List all servers in my Algolia infrastructure

Not supported: 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.

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.

Use Cases

Patterns agents use Algolia Monitoring API for, with concrete tasks.

★ 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.

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.

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.

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.

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

Key Endpoints

14 endpoints — jentic publishes the only available openapi specification for the algolia monitoring api, keeping it validated and agent-ready.

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

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

X-Algolia-Application-Id and X-Algolia-API-Key for infrastructure endpoints are stored in the Jentic vault. Agents receive scoped tokens; the raw Monitoring API key never enters their context.

Intent-based discovery

Agents search Jentic by intent (e.g. 'check Algolia cluster status' or 'get search latency') and Jentic returns the matching Monitoring operation with its input schema.

Time to first call

Direct integration: half a day to wire status polling, latency thresholds, and dashboard rendering. Through Jentic: under 15 minutes - search, load schema, execute.

FAQs

Specific to using Algolia Monitoring API through Jentic.

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 at https://app.jentic.com/sign-up.

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.