> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring Microservices

> Patterns for monitoring microservice architectures with uptime checks and health endpoints

Microservices need monitoring at multiple levels — individual service health, inter-service communication, and aggregate system status.

## The monitoring challenge

In a monolith, one health check covers the entire application. In microservices, you need to monitor:

* **Each service independently** — is the user service up? The payment service?
* **Service dependencies** — can service A reach service B?
* **Aggregate health** — is the overall system working for end users?
* **Shared infrastructure** — databases, message queues, caches

## Layer your monitoring

### Layer 1: External endpoint monitoring

Monitor the endpoints your users actually hit. These are your most important checks because they represent real user experience:

* API gateway health
* Public website availability
* Authentication endpoints

### Layer 2: Individual service health

Each microservice should expose a health endpoint that tests its own dependencies:

```json theme={null}
GET /health
{
  "status": "healthy",
  "dependencies": {
    "database": "connected",
    "cache": "connected",
    "messageQueue": "connected"
  }
}
```

### Layer 3: Inter-service communication

Monitor service-to-service calls:

* Can the order service reach the inventory service?
* Is the message queue processing events?
* Are internal API latencies within budget?

### Layer 4: Infrastructure

Monitor the shared components that multiple services depend on:

* Database clusters
* Message brokers (NATS, RabbitMQ, Kafka)
* Cache layers (Redis, Memcached)
* Service mesh / load balancers

## Health endpoint design

A good microservice health endpoint:

1. **Tests real dependencies** — actually queries the database, pings the cache
2. **Is fast** — returns in under 500ms (use timeouts on dependency checks)
3. **Is unauthenticated** — monitoring probes shouldn't need service credentials
4. **Returns structured data** — JSON with component-level status
5. **Distinguishes readiness from liveness** — "can accept traffic" vs "process is alive"

## Resource groups for composite health

Group related monitors into a single health view:

```
Payment Service (resource group)
  ├── Payment API health (HTTP)
  ├── Payment database (TCP:5432)
  ├── Stripe webhook handler (HTTP)
  └── Stripe status (dependency)
```

A resource group can define:

* **Health threshold** — "degraded if 2+ members are down"
* **Group-level alerts** — notify when the group's health drops
* **Suppress member alerts** — avoid alert storms from cascading failures

## Avoiding alert storms

When a shared dependency (database, DNS) fails, every service that depends on it fires an alert simultaneously. Mitigate this with:

* **Resource groups** with `suppressMemberAlerts` — one group alert instead of ten
* **Notification policy routing** — route by tag so infrastructure alerts go to the right team
* **Confirmation delays** — wait 30–60 seconds before confirming, allowing cascading failures to consolidate

## DevHelm for microservices

<CardGroup cols={2}>
  <Card title="Resource groups" icon="layer-group" href="/guides/resource-group-health">
    Build composite health views.
  </Card>

  <Card title="Monitor types" icon="signal" href="/monitoring/overview">
    HTTP, TCP, DNS, and heartbeat checks.
  </Card>
</CardGroup>