DEV Community

Vigilmon
Vigilmon

Posted on

Uptime Monitoring for Microservices: A Practical Guide with Vigilmon

#microservices #monitoring #architecture #devops

Microservices make uptime monitoring more complex than monolith monitoring. Instead of one service to watch, you have dozens of services with dependencies between them. This guide covers practical uptime monitoring strategies for microservice architectures using Vigilmon.

The Microservices Monitoring Challenge

In a monolith, you monitor one thing. In a microservice architecture:

  • 10-50+ individual services to monitor
  • Services have dependencies - if Service A calls Service B which calls Service C, failure propagates
  • An API gateway or load balancer can be up while services behind it are failing
  • Health checks at different layers give different views of system health

You need monitoring at multiple layers: infrastructure, service, and dependency.

Three Layers of Microservice Monitoring

Layer 1: API Gateway / Edge

Your API gateway is what users hit. If the gateway is down, everything is down for users even if all services are healthy.

Monitor: API gateway        api.yourapp.com         every 1 min
Monitor: Load balancer      yourapp.com             every 1 min
Enter fullscreen mode Exit fullscreen mode

Layer 2: Individual Services

Each service needs its own health check:

Monitor: User service         api.yourapp.com/users/health
Monitor: Payment service      api.yourapp.com/payments/health
Monitor: Order service        api.yourapp.com/orders/health
Monitor: Inventory service    api.yourapp.com/inventory/health
Monitor: Notification service api.yourapp.com/notifications/health
Enter fullscreen mode Exit fullscreen mode

Layer 3: Service Dependencies

Services have dependencies (databases, caches, queues). Each service's health endpoint should check its dependencies:

// Order service health endpoint
app.get('/health', async (req, res) => {
  const checks = await Promise.allSettled([
    checkDatabase(),        // MySQL
    checkCache(),           // Redis
    checkMessageQueue(),    // RabbitMQ
    checkInventoryService() // Dependency service
  ]);

  const results = {
    db: checks[0].status === 'fulfilled' ? 'ok' : 'error',
    cache: checks[1].status === 'fulfilled' ? 'ok' : 'error',
    queue: checks[2].status === 'fulfilled' ? 'ok' : 'error',
    inventory_service: checks[3].status === 'fulfilled' ? 'ok' : 'error'
  };

  const allHealthy = Object.values(results).every(v => v === 'ok');
  const statusCode = allHealthy ? 200 : 503;

  res.status(statusCode).json({
    service: 'order-service',
    status: allHealthy ? 'ok' : 'degraded',
    checks: results,
    timestamp: new Date().toISOString()
  });
});
Enter fullscreen mode Exit fullscreen mode

Setting Up Vigilmon for Microservices

Step 1: Create monitors for each service

In Vigilmon, create a monitor for every service's health endpoint:

Service               URL                                 Interval
API Gateway           https://api.yourapp.com/health      1 min
User Service          https://api.yourapp.com/users/h     3 min
Payment Service       https://api.yourapp.com/pay/h       3 min
Order Service         https://api.yourapp.com/orders/h    3 min
Enter fullscreen mode Exit fullscreen mode

With Vigilmon's free tier, you can monitor unlimited services - no need to prioritize what to watch.

Step 2: Use keyword checks to verify service logic

HTTP 200 alone is not enough. A service might return 200 with error content. Add keyword checks:

URL: https://api.yourapp.com/payments/health
Expected status: 200
Keyword check: "\"status\":\"ok\""
Enter fullscreen mode Exit fullscreen mode

This ensures the health endpoint is actually reporting healthy, not just responding.

Step 3: Configure alert escalation

For microservices, configure alerts based on service criticality:

Revenue-critical services (page immediately):

  • API gateway
  • Payment service
  • Order service
  • Authentication service

Supporting services (Slack notification):

  • Notification/email service
  • Analytics service
  • Search service

Internal tools (email only):

  • Admin dashboards
  • Background job managers

Step 4: Monitor service dependencies separately

If your payment service depends on an external provider (Stripe, PayPal), monitor those too:

Monitor: Stripe connectivity    Check Stripe's status endpoint
Monitor: Payment gateway IP     TCP check on payment processor endpoint
Enter fullscreen mode Exit fullscreen mode

Health Endpoint Design for Microservices

Good health endpoints for microservices follow a consistent pattern:

{
  "service": "order-service",
  "version": "2.4.1",
  "status": "ok",
  "uptime_seconds": 86400,
  "checks": {
    "database": "ok",
    "redis": "ok",
    "rabbitmq": "ok",
    "inventory_service": "degraded"
  },
  "timestamp": "2026-08-03T08:00:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Return 200 when all checks pass. Return 503 when any critical dependency fails. Return 207 (Multi-Status) when some checks fail but the service can still operate in degraded mode.

Distinguishing Service Failure from Dependency Failure

When a service's health check fails, you need to know: is the service itself broken, or is it a dependency?

Use cascading monitors:

  1. Monitor the dependency (database health endpoint)
  2. Monitor the service itself

If both fail simultaneously ? dependency failure
If only the service fails ? service-level issue

This reduces false pages and helps engineers immediately know where to look.

Heartbeat Monitoring for Background Workers

Microservice architectures often have background workers (queue consumers, scheduled jobs, data sync workers). Monitor these with heartbeats:

// Queue consumer worker
while (true) {
  const message = await queue.receive();
  await processMessage(message);

  // Ping heartbeat after each successful message
  await fetch('https://vigilmon.online/heartbeat/YOUR_TOKEN');
}
Enter fullscreen mode Exit fullscreen mode

If the consumer stops processing messages (queue backup, process crash, deadlock), the heartbeat stops - Vigilmon alerts you.

Monitoring Service Mesh and Internal Communication

If you use a service mesh (Istio, Linkerd), you have internal health data that external monitoring can't see. Expose aggregate health:

External monitor: api.yourapp.com/health    ? Shows aggregate system health
Internal mesh:    Istio/Linkerd dashboards  ? Shows inter-service communication
Enter fullscreen mode Exit fullscreen mode

External monitoring tells you what users experience. Internal metrics tell you why.

Sample Microservice Dashboard Layout 

EDGE
? API Gateway         99.99%   85ms
? CDN / Load Balancer 100%     12ms

CORE SERVICES
? Auth Service        99.98%   45ms
? User Service        99.97%   62ms
? Payment Service     99.95%   180ms
? Order Service       99.94%   220ms

SUPPORTING SERVICES
? Search Service      99.89%   340ms
? Notification Svc    99.71%   450ms
? Analytics Service   99.20%   (degraded)

BACKGROUND WORKERS
? Order Processor     Heartbeat: 4m ago (OK)
? Email Queue         Heartbeat: 2m ago (OK)
? Report Generator    Heartbeat: 45m ago (LATE)
Enter fullscreen mode Exit fullscreen mode

Start Monitoring Your Microservices

Set up free microservice monitoring at vigilmon.online. Unlimited monitors means you can watch every service without choosing what to cut.

Microservice downtime is complex - your monitoring should be comprehensive, not selective.

Top comments (0)