Better Stack Uptime API

Name: Better Stack Uptime API API
Brand: Better Stack Uptime API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring Observabilitybearer20 EndpointsREST

For Agents

Manage uptime monitors, heartbeats, incidents, and status pages on Better Stack. Pull response time and availability metrics for SLO reporting.

Quickstart

Get started with Better Stack Uptime API in minutes using your preferred integration method.

# Add to your MCP client config (Claude Desktop, Cursor, Windsurf)
{
  "jentic": {
    "url": "https://api.jentic.com/mcp",
    "auth": "oauth"
  }
}

# Then ask your agent:
"create an uptime monitor in better stack"

# → Jentic returns the GET /events tool with parameter schema, agent executes.

Capabilities

What an agent can do with Better Stack Uptime API API.

Create and manage HTTP and TCP uptime monitors

Track incidents and programmatically resolve them

Create and update public status pages

Retrieve response time samples for a monitor over a time window

GET STARTED

Start building with Better Stack Uptime API API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for Better Stack Uptime API, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for Better Stack Uptime API, keeping it validated and agent-ready. The Better Stack Uptime API follows the JSON:API specification and allows engineering teams to manage HTTP and TCP monitors, cron and worker heartbeats, incidents, and public status pages. It powers SRE-facing automation such as creating monitors when new services deploy, resolving incidents from chat ops, and pulling availability and response-time metrics for SLO reporting. The spec covers 20 endpoints scoped to v2.

Use Cases

Patterns agents use Better Stack Uptime API API for, with concrete tasks.

★ Auto-Provisioning Service Monitors

When a new service deploys to production, automatically create matching uptime monitors so the on-call team has visibility from minute one. POST /monitors takes the URL, expected status code, and check interval, and returns the monitor id for tagging in the deployment metadata. Wiring this into a deploy pipeline is typically half a day of work.

On deploy, POST /monitors with the new service URL and 30-second check interval, then store the returned monitor_id alongside the service record

Cron Job Heartbeat Tracking

Use heartbeats to confirm that scheduled jobs ran on time. POST /heartbeats registers a heartbeat with an expected interval, and the job's runner pings the heartbeat URL each run. /heartbeats/{heartbeat_id} returns missed-run state for alerting. Setting up heartbeats for a fleet of cron jobs takes a few hours and immediately exposes silent failures.

POST /heartbeats with name and 60-minute period, then update the cron config to ping the returned heartbeat URL on each successful run

Chat-Ops Incident Resolution

Let engineers resolve Better Stack incidents from chat without context-switching to the dashboard. /incidents lists open incidents and POST /incidents/{incident_id}/resolve marks one resolved. Combined with a status page update via PATCH /status-pages/{status_page_id}, an on-call engineer can clear an outage in two API calls from the chat interface.

GET /incidents to list open issues, then POST /incidents/{incident_id}/resolve for the one named in the chat command and patch the status page

AI Agent for SRE Operations

An AI agent uses Jentic to discover Better Stack operations and assist on-call engineers: provisioning monitors, summarising open incidents, or pulling availability for an SLO report. The agent searches by intent, loads the operation schema, and executes against Better Stack without browsing the 20-endpoint reference. Through Jentic, integration takes under an hour.

Search Jentic for 'list open betterstack incidents' and execute /incidents, then summarise top 3 incidents by severity in the on-call channel

Key Endpoints

20 endpoints — jentic publishes the only available openapi specification for better stack uptime api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

POST

/monitors

Create an uptime monitor

GET

/monitors/{monitor_id}/response-times

Response time history for a monitor

GET

/monitors/{monitor_id}/availability

Availability percentage over a time window

POST

/heartbeats

GET

/incidents

List incidents

POST

/incidents/{incident_id}/resolve

Resolve an incident

POST

/status-pages

Create a status page

PATCH

/status-pages/{status_page_id}

Update a status page

POST

/monitors

Create an uptime monitor

GET

/monitors/{monitor_id}/response-times

Response time history for a monitor

GET

/monitors/{monitor_id}/availability

Availability percentage over a time window

POST

/heartbeats

GET

/incidents

List incidents

Why though Jentic?

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

Credential isolation

Better Stack bearer tokens are stored encrypted in the Jentic vault. Agents receive scoped execution rights — the Authorization header is injected at execution time and never appears in the agent's context window.

Intent-based discovery

Agents search Jentic by intent such as 'create uptime monitor' or 'resolve incident' and Jentic returns the matching Better Stack operation with its parameter schema, removing the need to read the JSON:API reference manually.

Time to first call

Direct Better Stack integration: 1 to 2 days for token onboarding, JSON:API request shaping, and pagination. Through Jentic: under 1 hour — search, load schema, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

PagerDuty API

On-call routing for Better Stack incidents into the right responder

Use PagerDuty for paging, escalation, and schedules; pair with Better Stack monitors and incidents that signal the underlying outage.

Alternative

Statuspage API

Atlassian's public status page product as an alternative to Better Stack status pages

Pick Statuspage if your stack is Atlassian-centric; pick Better Stack to keep monitors, heartbeats, and status pages in one platform.

FAQs

Specific to using Better Stack Uptime API API through Jentic.

Why is there no official OpenAPI spec for Better Stack Uptime API?

Better Stack publishes JSON:API documentation rather than an OpenAPI specification. Jentic generates and maintains this OpenAPI spec so that AI agents and developers can call Better Stack Uptime 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 Better Stack Uptime API use?

The Better Stack Uptime API uses HTTP Bearer authentication — clients send Authorization: Bearer <token> on every request, where the token comes from the Better Stack team API tokens page. When called via Jentic, the token is stored encrypted in the Jentic vault and injected at execution time so it never appears in the agent's context.

Can I resolve an incident programmatically?

Yes. POST /incidents/{incident_id}/resolve marks the incident resolved without further input. GET /incidents lists current incidents, and GET /incidents/{incident_id} returns the full timeline so a chat-ops or runbook integration can present context before resolving.

How do I create a heartbeat through Jentic?

Run pip install jentic and search for 'create betterstack heartbeat'. Jentic returns POST /heartbeats, the agent loads the schema, and executes with name and expected period. Use the returned heartbeat URL as the ping target in your scheduled job runner.

What rate limits apply to the Better Stack Uptime API?

Better Stack applies per-token rate limits documented in the developer portal; the OpenAPI spec does not encode these explicitly. Honour 429 responses with backoff, and prefer pulling /monitors/{monitor_id}/availability over polling /monitors/{monitor_id}/response-times for SLO summaries.

Can I retrieve response time history for a monitor?

Yes. GET /monitors/{monitor_id}/response-times returns response time samples for a monitor over a configurable window, suitable for charting or anomaly detection. Pair with GET /monitors/{monitor_id}/availability when reporting SLO compliance.