The port check is green and search is broken: monitoring an on-premises MDM server

HTTP/1.1 200 OK

{
  "status": "error",
  "database": "disconnected",
  "message": "Failed to connect to localhost:1433",
  ...
}

We sell Primentra as on-premises master data management, and that comes with a cost nobody puts in the comparison spreadsheet: you watch the server. A SaaS vendor has someone on call for its own machines. When the MDM runs on your SQL Server, nobody watches it unless your team sets that up. If nobody does, your first alert is a data steward writing to the helpdesk on Monday morning.

Most teams already run a monitoring tool. PRTG, Zabbix, SCOM, a scheduled PowerShell job: something checks that the server answers on port 3001. That proves the Windows service runs, and says nothing about the database behind it.

Up, and broken anyway

We know of four ways a Primentra server fails. A port check catches one of them.

SQL Server stops answering

Someone patches the instance and it does not come back. Or the service account's password changes, or its login locks after too many failed attempts. The Primentra service keeps running and keeps answering on its port. Nobody can sign in, and the port check stays green.

The upgrade stops halfway

An upgrade replaces the program files first. The database schema changes after that, and only an administrator can start that step, from the browser. Install on Friday evening, close the browser before the schema step, and on Monday every other user sees a Database upgrade required screen and waits for you.

Full-text search stops

Full-Text Search is optional in Primentra. Without it, search uses LIKE and finds the same rows, only slower. With it, the indexes depend on a Windows service few people recognize by name: SQL Full-text Filter Daemon Launcher.

A hardening script disables that service, or it does not start, and SQL Server refuses full-text queries with error 0x80070422. Search in the grid then fails. Editing and saving still work, so the fault can sit there for days before a steward mentions it.

The service is gone

Nothing answers on the port. Your port check catches this one.

What the health check reports

Primentra answers GET /api/health on its own port, http://your-server:3001/api/health on a default install. It needs no sign-in, so your monitoring tool needs no Primentra account. Behind IIS, the same path works on the address your users open, because IIS forwards /api to the service.

This is the reply from our own development server. It has no Full-Text Search installed, so the four search fields read false:

{
  "status": "ok",
  "database": "connected",
  "tablesExist": true,
  "schemaVersion": "1.2026.10.15",
  "ftsInstalled": false,
  "ftsServiceRunning": false,
  "ftsWindowsService": false,
  "fullTextSearch": false,
  "ftsIndexCount": 0,
  "appVersion": "1.2026.10.15",
  "configBroken": false
}

Three fields carry the alerts:

If ftsInstalled is false, you never installed Full-Text Search, and there is nothing to alert on. The Health & Monitoring page lists every field.

A 200 that means down

Look at the two panels at the top again. When SQL Server is down, the endpoint still answers, so HTTP says 200. Only the body says the database is gone. Monitoring that alerts on the status code stays green through the whole outage.

Most HTTP checks can require a phrase in the reply. Require "status":"ok" with no space after the colon, because that is how Primentra writes it on the wire. The pretty-printed version above has spaces; the real reply does not.

A check you can schedule

If your tool cannot read JSON, this PowerShell script can. It exits 0 when all is well, 1 for a fault that needs a person today, and 2 when Primentra is down. We ran it against a live server and against a port with nothing on it before we put it here.

param($url = 'http://mdm-server:3001/api/health')
try {
    $r = Invoke-RestMethod -Uri $url -TimeoutSec 10
} catch {
    Write-Output "DOWN: no answer from $url"; exit 2
}
if ($r.status -ne 'ok') { Write-Output "DOWN: $($r.message)"; exit 2 }
if ($r.schemaVersion -ne $r.appVersion) {
    Write-Output "UPGRADE NOT FINISHED: schema $($r.schemaVersion), app $($r.appVersion)"; exit 1
}
if ($r.ftsInstalled -and -not $r.fullTextSearch) {
    Write-Output 'SEARCH BROKEN: check the SQL Full-text Filter Daemon Launcher'; exit 1
}
Write-Output 'OK'

Run it from Task Scheduler every five minutes, on a different machine. A check that runs on the Primentra server stops with the server. The endpoint allows 500 requests per 15 minutes from one address, so even a check every minute uses 15 of them.

What it does not watch

The health reply says nothing about SQL Server Agent. Primentra's scheduler is an Agent job. It runs the scheduled staging loads and deletes old log rows. Stop the Agent and both stop, while the reply still says ok. Add the SQL Server Agent service to the Windows service checks your tool already runs.

Disk space and backups stay with the SQL Server monitoring you have today. The health check covers what your DBA tools cannot see, which is whether the application on top of the database works.

Common questions

Want Full-Text Search on an instance you already run? Install SQL Server shows how to add it, and the 60-day trial runs on your own server.