Your Microcks instance is the source of truth for every API mock your team depends on during development and CI. A broken mock service means developers hit 502s instead of realistic test responses. A failed async broker connection silently drops event-driven mock messages. And when Microcks' test execution service goes down, your API conformance pipeline passes by default — hiding real contract violations.
Microcks is an open-source API mocking and testing server that supports REST, GraphQL, gRPC, and event-driven APIs. Built on Java/Quarkus, it runs on port 8080 and integrates with Kafka, AMQP, and other brokers for async API simulation. Self-hosting Microcks is common in enterprise API-first shops — and it deserves the same external monitoring you'd apply to any production service.
Vigilmon watches Microcks from the outside. This tutorial shows you how to catch UI outages, broken mock pipelines, and test execution failures before your developers or CI pipelines do.
What You'll Build
- An HTTP monitor on Microcks' web UI and health endpoint
- A mock service health check via the REST API
- An API import pipeline probe
- An async mock broker connectivity monitor
- A test execution service check
- Alert channels for your team
Prerequisites
- A self-hosted Microcks instance (v1.9+ recommended)
- Default port: 8080 (HTTP)
- A free account at vigilmon.online
Step 1: Monitor Microcks Web UI Availability
Microcks exposes a /api/health endpoint specifically for health checks — no authentication required. This is the fastest signal for whether Microcks is running and its database connection is healthy.
Test it:
curl http://your-microcks-host:8080/api/health
Expected response:
{
"status": "UP",
"checks": [
{
"name": "database",
"status": "UP"
}
]
}
A "status": "UP" response confirms Quarkus is running, the MongoDB (or Mongo-compatible) backend is connected, and Microcks can serve mock definitions.
Set up the Vigilmon monitor:
- Log in to Vigilmon and click New Monitor → HTTP.
- Set URL to
http://your-microcks-host:8080/api/health. - Set Check interval to 60 seconds.
- Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword present:
"UP" - Keyword absent:
"DOWN"
- Keyword present:
- Save the monitor.
This single monitor catches the most common Microcks failures: process crash, out-of-memory kill, and database connectivity loss.
Step 2: Monitor the Web UI with Keyword Verification
The health API passing doesn't guarantee the web interface is serving correctly. Add a separate monitor on the UI root that checks for actual UI content — catching cases where the static frontend build is corrupted or the UI proxy layer breaks.
curl -o /dev/null -s -w "%{http_code}" http://your-microcks-host:8080/
The Microcks web UI should return 200 with HTML that includes the application title.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-microcks-host:8080/. - Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword present:
"Microcks"
- Keyword present:
- Set Check interval to 120 seconds.
- Save the monitor.
The keyword check catches a scenario where Nginx or Caddy is serving a static 200 error page while the Microcks app itself is failing to start.
Step 3: Monitor Mock Service Health via the REST API
Microcks' core value is serving mock responses. Verify that the mock serving pipeline is operational by querying the services list API — this exercises the data layer and mock routing in a single call:
curl http://your-microcks-host:8080/api/services?page=0&size=1
If Microcks has any imported API definitions, this returns a JSON array. Even an empty array confirms the API is routing correctly. A 500 or connection refused means the mock serving pipeline is broken.
If you require authentication on your Microcks instance, obtain a service account token first:
TOKEN=$(curl -s -X POST http://your-keycloak:8080/realms/microcks/protocol/openid-connect/token \
-d "client_id=microcks-serviceaccount&client_secret=YOUR_SECRET&grant_type=client_credentials" \
| jq -r .access_token)
curl http://your-microcks-host:8080/api/services?page=0&size=1 \
-H "Authorization: Bearer $TOKEN"
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-microcks-host:8080/api/services?page=0&size=1. - Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword present:
"totalCount"or"[]"(whichever your version returns on empty)
- Keyword present:
- Set Check interval to 120 seconds.
- Save the monitor.
Step 4: Monitor the API Import Pipeline
Microcks imports API definitions from URLs, Git repositories, or direct upload. The import job endpoint lets you probe whether the import scheduler is alive:
curl http://your-microcks-host:8080/api/jobs?page=0&size=1
This returns the list of scheduled import jobs. A healthy response confirms that the import pipeline service is running and its scheduling backend is connected.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-microcks-host:8080/api/jobs?page=0&size=1. - Set Expected status code to
200. - Set Check interval to 300 seconds (5 minutes is sufficient for the import scheduler).
- Save the monitor.
If your Microcks instance requires authentication for this endpoint, add an Authorization header using a long-lived service account token stored in Vigilmon's secret store.
Step 5: Monitor Async Mock Broker Connectivity
Microcks can simulate event-driven APIs over Kafka, AMQP, MQTT, and WebSocket. If the broker connection drops, async API mocks silently stop emitting events — causing async consumer tests to time out without a clear error.
Microcks surfaces broker connection status through its health endpoint under the checks array:
curl http://your-microcks-host:8080/api/health
When async features are enabled, the response includes an entry for each configured broker:
{
"status": "UP",
"checks": [
{ "name": "database", "status": "UP" },
{ "name": "kafka", "status": "UP" }
]
}
Update your health endpoint monitor (from Step 1) to also verify broker status:
- Edit the monitor you created in Step 1.
- Under Advanced → Keyword check, extend the assertion:
- Keyword present:
"UP"(covers all UP entries) - Keyword absent:
"DOWN"
- Keyword present:
- Save the updated monitor.
If a broker is unhealthy, the health response will include "status": "DOWN" for that check — the keyword monitor catches it.
For deeper broker health (Kafka partition lag, AMQP queue depth), add dedicated infrastructure monitors for those systems separately.
Step 6: Monitor Test Execution Service
Microcks runs conformance tests against real API endpoints. If the test execution service crashes, your CI pipeline will queue test runs that never complete. Monitor the tests API endpoint to confirm the test runner is available:
curl http://your-microcks-host:8080/api/tests?page=0&size=1
A JSON response (even an empty array of past tests) confirms the test execution service is up and its result store is accessible.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-microcks-host:8080/api/tests?page=0&size=1. - Set Expected status code to
200. - Set Check interval to 300 seconds.
- Save the monitor.
Step 7: Alert Channels
Go to Notifications → New Channel in Vigilmon and configure:
- Email — alerts to your API platform team
- Webhook — Slack or PagerDuty integration
A failing Microcks health check in Slack looks like:
🔴 DOWN: microcks-health (HTTP monitor)
Response contains "DOWN" — keyword check failed
Region: EU-West
Triggered: 2026-02-14 09:31 UTC
When Microcks recovers:
✅ RECOVERED: microcks-health
Downtime: 4 minutes
Set critical-severity alerts for the health endpoint monitor (it covers database and broker connectivity). Use informational alerts for the import job and test runner monitors.
What You've Built
| Scenario | How Vigilmon catches it |
|---|---|
| Microcks process crash | Health endpoint returns connection refused |
| MongoDB / database disconnected | Health endpoint returns "database": "DOWN" |
| Web UI serving error page | Keyword monitor misses "Microcks" in response |
| Kafka/AMQP broker connection lost | Health endpoint returns "kafka": "DOWN" |
| Import scheduler crash | /api/jobs endpoint returns 502 |
| Test execution service down | /api/tests endpoint returns 502 |
| Reverse proxy (Nginx/Caddy) failure | Public-URL monitor detects 502 |
Microcks is a critical part of the API-first development workflow — when it's down, developer productivity and CI reliability both suffer. External monitoring with Vigilmon ensures you catch Microcks failures before your team starts filing "why are my mocks 502ing?" tickets.
Start monitoring your Microcks instance today — register free at vigilmon.online.