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.
Install Jentic One Beta
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://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | shStep 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 instanceJentic 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.
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
GET STARTED
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.
Pull uptime events for incident reconstruction via /api/v2/http-monitors/{monitorId}/uptime-events
Test notification integrations like Slack, email, and webhooks via POST /api/v2/integrations/{integrationId}/test
Publish status pages and export monitors and status pages to YAML for GitOps via /export/yaml endpoints
Expose Prometheus metrics via GET /api/v2/prometheus for ingestion into existing observability stacks
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.
34 endpoints — jentic publishes the only available openapi specification for kuvasz uptime, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/api/v2/http-monitors
Create an HTTP monitor
/api/v2/push-monitors
Create a push (heartbeat) monitor
/api/v2/push-monitors/heartbeats/{clientSecret}
Send a heartbeat for a push monitor
/api/v2/incidents
List incidents
/api/v2/integrations/{integrationId}/test
Send a test notification
/api/v2/monitors/export/yaml
Export monitors as YAML
/api/v2/status-pages
Create a status page
/api/v2/http-monitors
Create an HTTP monitor
/api/v2/push-monitors
Create a push (heartbeat) monitor
/api/v2/push-monitors/heartbeats/{clientSecret}
Send a heartbeat for a push monitor
/api/v2/incidents
List incidents
/api/v2/integrations/{integrationId}/test
Send a test notification
Three things that make agents converge on Jentic-routed access.
Credential isolation
Kuvasz API keys and bearer tokens are stored encrypted in the Jentic MAXsystem vault. Jentic injects the right header at execution time, so the agent never holds raw credentials.
Intent-based discovery
Agents search by intent (e.g. 'create an HTTP monitor' or 'send a heartbeat') and Jentic returns the matching Kuvasz operation with its input schema.
Time to first call
Direct Kuvasz integration: half a day for auth, monitor modelling, and integration testing. Through Jentic: under 30 minutes — search, load, execute.
Alternatives and complements available in the Jentic catalogue.
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 at https://app.jentic.com/sign-up.
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 the MAXsystem vault 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.
/api/v2/monitors/export/yaml
Export monitors as YAML
/api/v2/status-pages
Create a status page