Scale and Monitor Micronaut in Production

By Khimananda Oli | Last reviewed: August 2026

Micronaut’s low-memory footprint and fast startup make it ideal for cloud-native Java, but default configurations rarely survive real traffic spikes or audit reviews. To reliably scale and monitor Micronaut in production, you must integrate Kubernetes Horizontal Pod Autoscaling (HPA) with custom Prometheus metrics and distributed tracing via OpenTelemetry. This combination ensures your services expand based on actual business load—not just CPU—while maintaining the observability required for SOC 2 compliance and rapid incident response.

How Do You Configure Micronaut for Production Observability?

Before you can scale intelligently, your application must expose the right signals. Micronaut’s compile-time DI makes this lightweight, but you need explicit module dependencies. For any team aiming to understand Prometheus metrics fundamentals, Micronaut’s native integration is a strong starting point.

Enable Micrometer and OpenTelemetry

Add these dependencies to your build.gradle or pom.xml. In 2026, use Micronaut 4.x+ with Micrometer 1.13+ and OpenTelemetry SDK 1.40+ for full compatibility.

// build.gradle.kts
implementation("io.micronaut.micrometer:micronaut-micrometer-registry-prometheus")
implementation("io.micronaut.opentelemetry:micronaut-opentelemetry")
implementation("io.opentelemetry:opentelemetry-exporter-otlp")

Configure Application Properties

In application.yml, expose metrics and enable tracing. Never run with default settings in production—always bind to specific paths and set sampling rates.

micronaut:
  metrics:
    enabled: true
    export:
      prometheus:
        enabled: true
        step: PT15S
  opentelemetry:
    enabled: true
    exporter:
      otlp:
        endpoint: https://otel-collector.internal:4317
        protocol: grpc
    sampler:
      ratio: 0.1 # Sample 10% of traces in prod

This configuration exposes /prometheus for scraping and sends traces via OTLP. The 10% sampling rate prevents trace volume from overwhelming your backend during peak load—a common mistake I see teams make when first adopting distributed tracing.

How Does Kubernetes HPA Work with Custom Micronaut Metrics?

CPU-based autoscaling fails for Java microservices because garbage collection and JIT compilation create misleading CPU spikes. Instead, scale on business-relevant metrics like HTTP requests per second or active connection count. This requires the Kubernetes HPA with custom metrics adapter.

Expose Custom Metrics via Micrometer

Micronaut automatically exports standard JVM and HTTP metrics. To add domain-specific counters, inject MeterRegistry:

@Singleton
public class OrderService {
    private final Counter orderCounter;

    public OrderService(MeterRegistry registry) {
        this.orderCounter = Counter.builder("orders.processed.total")
            .description("Total orders processed")
            .register(registry);
    }

    public void processOrder(Order order) {
        // business logic
        orderCounter.increment();
    }
}

Configure HPA with Custom Metrics

After installing the Prometheus Adapter in your cluster, define an HPA that targets your custom metric. This YAML assumes the adapter maps orders_processed_total to the Kubernetes custom metrics API.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: micronaut-order-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: orders_processed_per_second
      target:
        type: AverageValue
        averageValue: "50"

This scales pods when average throughput exceeds 50 orders/sec per replica. Always set minReplicas ≥ 2 for high availability—single-replica services violate basic resilience principles and fail most compliance audits.

What Are the Best Practices for Monitoring Micronaut Health and Performance?

Monitoring isn’t just dashboards—it’s defining what “healthy” means for your service. Align your monitoring strategy with the four golden signals: latency, traffic, errors, and saturation. Micronaut provides built-in health endpoints, but you must customize them for production.

Configure Liveness and Readiness Probes

Kubernetes uses these probes to restart unhealthy pods and remove unready ones from service load balancers. Misconfiguring them causes cascading failures during deployments.

endpoints:
  health:
    enabled: true
    sensitive: false
    details-visible: ANONYMOUS
liveness:
  enabled: true
  timeout: 3s
  interval: 10s
readiness:
  enabled: true
  timeout: 3s
  interval: 5s

Never use the same endpoint for both probes. Liveness should only check if the app can serve traffic (e.g., HTTP server running). Readiness should verify downstream dependencies (database, cache) are reachable. A pod that fails readiness but passes liveness stays alive but stops receiving new requests—this prevents error storms during partial outages.

Define SLIs and SLOs

Raw metrics are noise without context. Define Service Level Indicators (SLIs) and Objectives (SLOs) to distinguish signal from noise. For example:

• Availability SLI: sum(rate(http_server_requests_seconds_count{status=~"2.."}[5m])) / sum(rate(http_server_requests_seconds_count[5m]))
• SLO: 99.9% successful requests over 30 days
• Latency SLI: p95 of http_server_requests_seconds_bucket < 200ms

Track error budgets weekly. If you burn through your budget early, freeze feature releases until reliability recovers. This discipline separates mature teams from those constantly firefighting.

How Do Micronaut Scaling Strategies Compare for Cloud-Native Deployments?

Not all scaling approaches fit every workload. Choose based on your traffic patterns, compliance needs, and operational maturity. Below is a practical comparison grounded in real 2026 production deployments.

For most Micronaut services handling REST/gRPC traffic, HPA with custom metrics remains the gold standard. Reserve KEDA for async workers consuming Kafka or SQS queues. Avoid VPA for web-facing services—the mandatory restarts break user sessions and inflate error rates during scaling events.

Scale and Monitor Micronaut in Production: Your Next Steps

Getting scale and monitor Micronaut in production right requires treating observability as a first-class feature, not an afterthought. Start by enabling Prometheus metrics and OpenTelemetry tracing in your next sprint. Then implement HPA with at least one custom metric tied to business value. Finally, define one SLO per critical service and build a Grafana dashboard around it. These steps form the foundation of a compliant, resilient platform that survives both traffic spikes and auditor scrutiny.

If your team needs help designing a production-grade Micronaut observability stack or preparing for SOC 2 evidence collection, reach out to discuss your architecture. I’ve guided multiple fintech and SaaS teams through this exact transition in Nepal and globally.