Install Jentic One Beta

Connect the Kuvasz Uptime to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Kuvasz Uptime, 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://jentic.com/install.sh?src=apis&api=%2Fapis%2Fkuvasz-uptime.dev%2Fkuvasz-uptime" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fkuvasz-uptime.dev%2Fkuvasz-uptime" | 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 Kuvasz Uptime API.

Create HTTP monitors via POST /api/v2/http-monitors with target URL, method, and check interval

Send heartbeats from cron jobs and workers through GET or POST /api/v2/push-monitors/heartbeats/{clientSecret}

Inspect SSL certificate events for a monitor via GET /api/v2/http-monitors/{monitorId}/ssl-events

Pull uptime events for incident reconstruction via /api/v2/http-monitors/{monitorId}/uptime-events

GET STARTED

Start building with Kuvasz Uptime API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Kuvasz Uptime API for, with concrete tasks.

★ HTTP Endpoint Monitoring

Monitor public APIs and websites by creating HTTP monitors that probe a URL on a fixed interval. POST /api/v2/http-monitors creates the monitor, GET /api/v2/http-monitors/{monitorId}/uptime-events lists each up/down transition for incident reconstruction, and GET /api/v2/http-monitors/{monitorId}/ssl-events tracks certificate validity.

POST /api/v2/http-monitors with the target URL, then poll GET /api/v2/http-monitors/{monitorId}/uptime-events to surface transitions in the agent.

Cron Job Heartbeat Monitoring

Detect failed or skipped scheduled jobs by sending heartbeats from each run. POST /api/v2/push-monitors creates the monitor, the job sends a heartbeat to /api/v2/push-monitors/heartbeats/{clientSecret} on success and to the /failure variant on error. Kuvasz fires alerts via the configured integrations when heartbeats are missed.

POST /api/v2/push-monitors to create the heartbeat monitor, then call /heartbeats/{clientSecret} on every successful job run and /heartbeats/{clientSecret}/failure on failure.

GitOps Monitor Management

Manage monitors and status pages as code. GET /api/v2/monitors/export/yaml and GET /api/v2/status-pages/export/yaml return YAML descriptions that can be committed to Git, reviewed in PRs, and reapplied. This makes monitor configuration auditable and reproducible across environments.

GET /api/v2/monitors/export/yaml on a schedule and commit the result to a config repo when the diff is non-empty.

AI Agent SRE Assistant

An assistant in an SRE chat creates monitors on demand, tests notification integrations, and reports incident status without leaving the chat. Through Jentic, the assistant calls Kuvasz by intent with the API key kept in the vault.

On 'add a monitor for the new payments service', search Jentic for 'create Kuvasz HTTP monitor' and POST /api/v2/http-monitors with the URL and interval.

Key Endpoints

34 endpoints — jentic publishes the only available openapi specification for kuvasz uptime, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

POST

/api/v2/http-monitors

Create an HTTP monitor

POST

/api/v2/push-monitors

Create a push (heartbeat) monitor

POST

/api/v2/push-monitors/heartbeats/{clientSecret}

Send a heartbeat for a push monitor

GET

/api/v2/incidents

List incidents

POST

/api/v2/integrations/{integrationId}/test

Send a test notification

GET

/api/v2/monitors/export/yaml

Export monitors as YAML

POST

/api/v2/status-pages

Create a status page

POST

/api/v2/http-monitors

Create an HTTP monitor

POST

/api/v2/push-monitors

Create a push (heartbeat) monitor

POST

/api/v2/push-monitors/heartbeats/{clientSecret}

Send a heartbeat for a push monitor

GET

/api/v2/incidents

List incidents

POST

/api/v2/integrations/{integrationId}/test

Send a test notification

GET

/api/v2/monitors/export/yaml

Export monitors as YAML

POST

/api/v2/status-pages

Create a status page

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring Kuvasz Uptime by hand means choosing between its X-API-KEY and bearer auth, passing the right header on every call to your own Kuvasz host, and building the heartbeat and monitor request bodies yourself. Through Jentic you install once, import Kuvasz Uptime from the API Directory, store the credential once, and your agent calls it.

Permission scoping

Kuvasz's monitor and status-page operations take their targets in the request body rather than the URL path, so scope the agent to the operations it needs, such as reading incidents and sending heartbeats. You choose that set, so creating HTTP monitors or status pages is not included unless you add it.

Credential isolation

Your Kuvasz API key or bearer token is stored once, encrypted, by your own Jentic One instance, which injects the right header at execution time. The credential never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'create an HTTP monitor' or 'send a heartbeat', and Jentic returns the matching Kuvasz operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Kuvasz Uptime API through Jentic.

Why is there no official OpenAPI spec for Kuvasz Uptime?

Kuvasz does not publish an OpenAPI specification on a stable URL. Jentic generates and maintains this spec so that AI agents and developers can call Kuvasz Uptime 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 Kuvasz Uptime API use?

Kuvasz supports two schemes: an API key in the X-API-KEY header and HTTP bearer authentication. Through Jentic, both credential types are stored encrypted in your Jentic One instance and the right scheme is selected per request.

Can I send a heartbeat from a cron job with the Kuvasz Uptime API?

Yes. After creating a push monitor on POST /api/v2/push-monitors, send a GET or POST to /api/v2/push-monitors/heartbeats/{clientSecret} on success and to /api/v2/push-monitors/heartbeats/{clientSecret}/failure on error. Kuvasz alerts through configured integrations when heartbeats are missed.

How do I create an HTTP monitor through Jentic?

Search Jentic for 'create Kuvasz HTTP monitor'. Jentic returns POST /api/v2/http-monitors with its schema. Provide the URL and interval and Jentic executes the call using your stored credentials.

Is Kuvasz Uptime free to use?

Yes. Kuvasz is open-source and self-hostable. There are no licence fees; you bring your own host and database. The same v2 API runs on every Kuvasz instance.

Can I export Kuvasz monitors as YAML for GitOps?

Yes. GET /api/v2/monitors/export/yaml and GET /api/v2/status-pages/export/yaml return YAML representations suitable for committing to a Git repository, reviewing in pull requests, and reapplying.

Can I limit what my agent is allowed to do with the Kuvasz Uptime API?

Yes. Because you run Jentic One yourself, your own rules decide which Kuvasz operations and stored credentials the agent can use, so you can allow read-only calls like listing incidents on GET /api/v2/incidents and sending heartbeats to /api/v2/push-monitors/heartbeats/{clientSecret} while withholding write operations. Kuvasz takes its monitor and status-page targets in the request body rather than the URL path, so you scope by operation: creating HTTP monitors on POST /api/v2/http-monitors or status pages on POST /api/v2/status-pages is excluded unless you add it. The agent can only call the endpoints you grant, and the API key or bearer token stays under your control.

Kuvasz Uptime

AI ReadinessAI-Aware (B)64/100

See full scorecard

Agent-ready OpenAPI document · curated by JenticDeveloper ToolsMonitoring ObservabilityapiKey, bearer34 EndpointsREST

Know of an official OpenAPI document? Contribute it →

For Agents

Manage Kuvasz uptime monitors and status pages: create HTTP and push monitors, fetch SSL and uptime events, configure integrations, and run health checks.

Use for: I need to add an HTTP monitor for my API endpoint, I want to send a push heartbeat from my cron job, List all incidents in the last 24 hours, Get SSL certificate expiry events for a monitor

Not supported: Does not handle log aggregation, APM tracing, or on-call paging - use for uptime monitoring, heartbeats, and status pages only.

Jentic publishes the only available OpenAPI specification for Kuvasz Uptime, keeping it validated and agent-ready. Kuvasz is an open-source, self-hostable uptime monitoring and status page service. The v2 API covers HTTP and push monitor lifecycle, SSL events, uptime events, integrations, status pages, and Prometheus metrics, and supports both API key and bearer token authentication. Monitors and status pages can also be exported to YAML for GitOps-style management.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: ASignals: 4

97%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

100%

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

50%

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: C+Signals: 4

Example Density

How richly the API is illustrated with examples.

100%

Example Validity

Percentage of examples that conform to their schemas.

37%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

93%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: C-Signals: 4

69%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

74%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

60%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: CSignals: 1

55%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: BSignals: 1

64%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the Kuvasz Uptime to your agent

Capabilities

Start building with Kuvasz Uptime API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Kuvasz Uptime

Jentic AI Readiness Score

Kuvasz Uptime

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness