Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/LENINMORENO13/OpsMind/llms.txt

Use this file to discover all available pages before exploring further.

OpsMind exposes three observability endpoints that give you an instant window into the health of every service you track. The status/all endpoint fires a live HTTP probe against every registered monitor and returns results in one call. The status/:site endpoint lets you inspect a single service by name. The history endpoint surfaces the last 10 check logs for any monitor, giving you a short-horizon time series of status codes, response times, and trend signals. All three endpoints require a valid Authorization: Bearer <token> header.
OpsMind runs a background cron worker every 5 minutes that calls executeMonitorCheck for each active monitor. This means your history is continuously populated — even when no one calls these endpoints directly. By the time you query history for a monitor, there are already automated entries in the log.

​
Real-time status for all monitors

GET /api/v1/monitors/status/all runs a live HTTP check against every monitor registered in the system. It does not read cached data — each call in the response array reflects a fresh probe made at request time. Use this endpoint for dashboards, alerting webhooks, or any integration that needs an up-to-the-second view across your entire fleet.
cURL
curl https://opsmind-e07b.onrender.com/api/v1/monitors/status/all \
  -H "Authorization: Bearer <token>"
Success — 200 OK
Response
{
  "success": true,
  "data": [
    {
      "id": 1,
      "name": "Main API",
      "url": "https://api.myapp.com/health",
      "status": 200,
      "message": "OK",
      "trend": "STABLE",
      "state": "UP"
    },
    {
      "id": 2,
      "name": "Dashboard",
      "url": "https://dashboard.myapp.com",
      "status": 503,
      "message": "Service Unavailable",
      "trend": "DROP_DETECTED",
      "state": "DOWN"
    }
  ]
}
Response fields per monitor
FieldTypeDescription
idintegerMonitor primary key
namestringMonitor display name
urlstringThe endpoint that was probed
statusintegerHTTP status code returned by the probe
messagestringHuman-readable status message from the probe
trendTrendStatusDirectional signal: STABLE, RECOVERED, DROP_DETECTED, OFFLINE
stateServiceStatusCurrent health state: UP, DOWN, DEGRADED, PENDING

​
Status for a single monitor by name

GET /api/v1/monitors/status/:site runs the same live probe as the bulk endpoint, but targets a single monitor looked up by its name field. The lookup is case-insensitive, so "Payment API", "payment api", and "PAYMENT API" all resolve to the same monitor.
cURL
curl "https://opsmind-e07b.onrender.com/api/v1/monitors/status/payment%20api" \
  -H "Authorization: Bearer <token>"
Success — 200 OK
Response
{
  "success": true,
  "data": {
    "id": 3,
    "status": 200,
    "responseTime": 142,
    "error": null,
    "trend": "STABLE",
    "state": "UP",
    "timestamp": "2025-01-15T10:45:00.000Z",
    "monitorId": 3
  }
}
Error cases
StatusCondition
404No monitor whose name matches :site (case-insensitive) — "Site not monitored"
401Missing or invalid JWT token
500Error during probe execution

​
Monitor history

GET /api/v1/monitors/:id/history returns the last 10 Log records for the specified monitor, ordered newest first. Each log entry is written by executeMonitorCheck — either via the cron worker or when a status endpoint is called.
cURL
curl https://opsmind-e07b.onrender.com/api/v1/monitors/1/history \
  -H "Authorization: Bearer <token>"
Success — 200 OK
Response
{
  "success": true,
  "data": [
    {
      "id": 198,
      "status": 200,
      "responseTime": 134,
      "error": null,
      "trend": "STABLE",
      "state": "UP",
      "timestamp": "2025-01-15T11:00:00.000Z",
      "monitorId": 1
    },
    {
      "id": 197,
      "status": 200,
      "responseTime": 148,
      "error": null,
      "trend": "RECOVERED",
      "state": "UP",
      "timestamp": "2025-01-15T10:55:00.000Z",
      "monitorId": 1
    },
    {
      "id": 196,
      "status": 503,
      "responseTime": 5001,
      "error": "Service Unavailable",
      "trend": "DROP_DETECTED",
      "state": "DOWN",
      "timestamp": "2025-01-15T10:50:00.000Z",
      "monitorId": 1
    },
    {
      "id": 195,
      "status": 200,
      "responseTime": 122,
      "error": null,
      "trend": "STABLE",
      "state": "UP",
      "timestamp": "2025-01-15T10:45:00.000Z",
      "monitorId": 1
    }
  ]
}
Log record fields
FieldTypeDescription
idintegerAuto-incremented log entry ID
statusintegerHTTP status code recorded during this check
responseTimeintegerRound-trip response time in milliseconds
errorstring | nullError detail if the probe failed; null on success
trendTrendStatusDirectional signal computed relative to the previous check
stateServiceStatusHealth classification at the time of this check
timestampdatetimeISO 8601 timestamp when the log was created
monitorIdintegerForeign key back to the parent Monitor record
Error cases
StatusCondition
400:id is not a valid integer
404No monitor found with the given id
401Missing or invalid JWT token
500Unexpected server error

​
Interpreting the data

The trend and state fields work together to give you a nuanced picture of service health over time. state is a snapshot — the absolute health classification at a single point in time. trend is a delta — it captures how the current check compares to the previous one.

STABLE + UP

The service has been healthy for consecutive checks. No action needed.

DROP_DETECTED + DOWN

The service just became unreachable or returned an error after a previously healthy check. An AI Insight is generated automatically by Gemini when this combination is detected.

RECOVERED + UP

The service has returned to a healthy state after a previous failure. Good signal for incident post-mortems.

OFFLINE + DOWN

The service has been unreachable across multiple consecutive checks. Indicates a sustained outage rather than a transient blip.
When you see trend: "DROP_DETECTED" in a log entry, OpsMind has also queried the Google Gemini AI for a root-cause analysis and stored the result as an AIInsight linked to that monitor. These insights include a probable cause and a recommended remediation action.

Build docs developers (and LLMs) love

Get started for freeTalk to us