GET /api/v1/monitors/:id/history — Monitor Log History

Every time OpsMind runs a health check — whether triggered by a background cron job or by a direct call to one of the real-time status endpoints — the result is persisted as a row in the Log table. This endpoint retrieves the 10 most recent of those persisted records for a specific monitor, ordered by timestamp descending (newest first). The log entries expose the raw HTTP status code, response time in milliseconds, operational state, trend direction, and any network error string that was captured during the probe. This makes the history endpoint the primary tool for spotting patterns such as recurring degradation windows, flapping services, or prolonged outages.

Endpoint

GET /api/v1/monitors/:id/history

Authorization

string

required

A valid JWT issued by the /api/v1/auth/login endpoint.
Format: Bearer <token>

Path Parameters

integer

required

The numeric primary-key identifier of the monitor whose log history you want to retrieve. Must be a valid integer — the server calls parseInt() and returns 400 if the result is NaN. You can discover monitor IDs from the GET /api/v1/monitors list endpoint.

Request

This endpoint takes no query parameters or request body.

Example

curl -X GET https://opsmind-e07b.onrender.com/api/v1/monitors/4/history \
  -H "Authorization: Bearer <token>"

Response

200 — Success

Returns a JSON object with a success flag and a data array of up to 10 Log records, ordered by timestamp descending.

{
  "success": true,
  "data": [ ... ]
}

success

boolean

Always true on a successful response.

data

array

Array of up to 10 Log table records for the requested monitor, newest first.

Show Log record fields

integer

The auto-incrementing primary key of the log entry in the Log table.

monitorId

integer

Foreign key referencing the parent Monitor record. Matches the :id path parameter used in the request.

status

integer

The raw HTTP response code captured during the probe. Common values:

Code	Meaning
`200`	Service responded successfully
`404`	Endpoint or resource not found
`500`	Target server encountered an internal error
`0`	No response — connection timed out or was refused

responseTime

integer

The number of milliseconds the probe took from request dispatch to response receipt (or timeout). Stored directly from the Date.now() delta measured by checker.js.

error

string | null

The raw error message string if the HTTP probe threw a network-level exception (e.g., "connect ECONNREFUSED 127.0.0.1:3001", "timeout of 5000ms exceeded"). null when the probe completed without a network-level error, even if the service returned a non-2xx HTTP code.

trend

TrendStatus enum

The trend direction computed by analyzer.js at the time this log entry was created, by comparing the probe result against the immediately preceding log entry. Possible values:

Value	Description
`STABLE`	State is unchanged compared to the previous check
`DROP_DETECTED`	Service degraded or went offline since the last check
`RECOVERED`	Service came back up after a prior `DOWN` or `DEGRADED` state
`OFFLINE`	Service has been unreachable across consecutive checks

state

ServiceStatus enum

The operational state of the monitor as assessed during this specific check. Possible values:

Value	Condition
`UP`	Online and responding within 1500 ms
`DEGRADED`	Online but response time exceeded 1500 ms
`DOWN`	Probe failed — no HTTP response received
`PENDING`	No prior log record existed at the time of this check

timestamp

datetime

ISO 8601 UTC timestamp set by Prisma’s @default(now()) when the log row was inserted. Represents when the health check was recorded, not when the probe was initiated. Example: "2025-07-14T10:32:05.000Z".

Sample Response

The following example shows three consecutive log entries illustrating a drop, an extended outage, and then a recovery:

{
  "success": true,
  "data": [
    {
      "id": 187,
      "monitorId": 4,
      "status": 200,
      "responseTime": 289,
      "error": null,
      "trend": "RECOVERED",
      "state": "UP",
      "timestamp": "2025-07-14T11:15:02.000Z"
    },
    {
      "id": 186,
      "monitorId": 4,
      "status": 0,
      "responseTime": 5003,
      "error": "timeout of 5000ms exceeded",
      "trend": "OFFLINE",
      "state": "DOWN",
      "timestamp": "2025-07-14T11:10:01.000Z"
    },
    {
      "id": 185,
      "monitorId": 4,
      "status": 500,
      "responseTime": 1823,
      "error": null,
      "trend": "DROP_DETECTED",
      "state": "DEGRADED",
      "timestamp": "2025-07-14T11:05:00.000Z"
    }
  ]
}

Log entries are written by two sources: the background cron scheduler (which probes every monitor at its configured checkInterval, defaulting to every 5 minutes) and any direct call to the real-time status endpoints (GET /status/all or GET /status/:site). Both paths run executeMonitorCheck, which always persists a new Log row before returning. Keep this in mind when interpreting timestamps — gaps smaller than the cron interval indicate manual status checks were made.

Error Responses

400 — Invalid ID Format

Returned when the :id path segment cannot be parsed as an integer (e.g., GET /api/v1/monitors/abc/history).

{
  "success": false,
  "error": "Invalid ID format"
}

404 — Monitor Not Found

Returned when the provided integer ID does not match any monitor in the database.

{
  "success": false,
  "error": "Monitor not found"
}

401 — Unauthorized

Returned when the Authorization header is missing, malformed, or contains an expired or invalid JWT.

{
  "success": false,
  "error": "Unauthorized"
}

500 — Internal Server Error

Returned when an unexpected error occurs while querying the Log table.

{
  "success": false,
  "error": "Internal server error"
}

Authentication

Monitors

Observability

GET /api/v1/monitors/:id/history — Monitor Log History

Endpoint

Path Parameters

Request

Example

Response

200 — Success

Sample Response

Error Responses

400 — Invalid ID Format

404 — Monitor Not Found

401 — Unauthorized

500 — Internal Server Error

Build docs developers (and LLMs) love

Authentication

Monitors

Observability

Documentation Index

​Endpoint

​Path Parameters

​Request

​Example

​Response

​200 — Success

​Sample Response

​Error Responses

​400 — Invalid ID Format

​404 — Monitor Not Found

​401 — Unauthorized

​500 — Internal Server Error

Build docs developers (and LLMs) love

Endpoint

Path Parameters

Request

Example

Response

200 — Success

Sample Response

Error Responses

400 — Invalid ID Format

404 — Monitor Not Found

401 — Unauthorized

500 — Internal Server Error