Monitoring MinIO Object Storage with Vigilmon: Health Endpoints, Bucket Availability & SSL Certificate Alerts

MinIO is the go-to self-hosted S3-compatible object storage solution — used for development environments, on-premises deployments, ML training data pipelines, and air-gapped infrastructure where AWS S3 isn't an option. When MinIO goes down or degrades, uploads fail, downloads return errors, and applications that depend on object storage break in ways that produce confusing application-layer errors rather than clear storage messages. Vigilmon gives you external visibility into MinIO's health: the built-in liveness and readiness endpoints, bucket availability, and SSL certificates — so you catch failures before they cascade into data pipeline outages.

What You'll Build

• A monitor on MinIO's /minio/health/live liveness endpoint
• A readiness monitor on /minio/health/ready that catches degraded and healing states
• A bucket availability check using a pre-signed URL probe object
• SSL certificate monitoring for your MinIO domain
• Alerting that distinguishes process failures from disk/cluster degradation

Prerequisites

• A running MinIO instance (standalone or distributed) with HTTP or HTTPS API access
• MinIO endpoint accessible at a public or network-reachable URL (e.g., https://minio.example.com)
• A free account at vigilmon.online

Step 1: Verify MinIO's Health Endpoints

MinIO ships with two health endpoints out of the box — no configuration required:

# Liveness: is the process running?
curl -I https://minio.example.com/minio/health/live

# Readiness: can it serve requests?
curl -I https://minio.example.com/minio/health/ready

A healthy MinIO returns HTTP/1.1 200 OK for both. A degraded or offline MinIO returns 503 Service Unavailable or a connection error.

The two endpoints serve different purposes:

• /minio/health/live: Confirms the MinIO process is running. Returns 200 as long as the process is alive, even if disks are unhealthy.
• /minio/health/ready: Confirms MinIO can serve read and write requests. Returns 503 when a disk is offline, when MinIO is healing after a disk replacement, or when a distributed cluster doesn't have the minimum required drives online.

Step 2: Create a Vigilmon Monitor for MinIO Liveness

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://minio.example.com/minio/health/live.
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Click Save.

This is your baseline: if the liveness monitor fires, the MinIO process has crashed and all storage operations are failing immediately.

Step 3: Create a Vigilmon Monitor for MinIO Readiness

The readiness monitor is the more actionable production check — it catches disk failures and cluster degradation that the liveness check misses:

1. Add Monitor → HTTP.
2. URL: https://minio.example.com/minio/health/ready.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds (distributed clusters may take longer to respond under disk stress).
5. Expected status: 200.
6. Label: MinIO Readiness.
7. Click Save.

This monitor fires when:

• A disk is offline or unmounted
• MinIO is healing after a disk replacement (during healing, new writes may fail)
• A distributed deployment drops below the minimum required drives for quorum
• MinIO enters maintenance mode

Step 4: Monitor SSL Certificates

If your MinIO is served over HTTPS (required in production), add SSL certificate monitoring:

1. Add Monitor → SSL Certificate.
2. Domain: minio.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

If you also expose the MinIO Console on a separate subdomain (e.g., console.minio.example.com), add a second SSL monitor for that domain. MinIO clients that use TLS verification will start failing immediately on certificate expiry with cryptic TLS handshake errors rather than helpful messages about the certificate.

Step 5: Monitor Bucket Availability with a Probe Object

HTTP status codes tell you whether MinIO is running, but not whether it can actually serve bucket operations. Add an end-to-end check using a probe object in a dedicated health-check bucket:

Create the probe object (run once):

# Configure MinIO client
mc alias set myminio https://minio.example.com minioadmin minioadmin

# Create a dedicated monitoring bucket
mc mb myminio/health-check

# Upload a tiny probe object
echo '{"status":"ok"}' | mc pipe myminio/health-check/probe.json

# Generate a long-lived pre-signed URL (1 year)
mc share download --expire 8760h myminio/health-check/probe.json

Add the Vigilmon monitor:

1. Add Monitor → HTTP.
2. URL: The pre-signed URL from the mc share download output (it contains the signature and expiry as query parameters).
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Keyword: "status":"ok".
6. Label: MinIO bucket operations.

This proves MinIO can serve actual bucket content. When this monitor fires but the liveness monitor is green, you have a bucket permission, policy, or storage layer issue rather than a process failure.

Step 6: Monitor the MinIO Console

If you expose the MinIO administration console (default port 9001), add a monitor for it:

1. Add Monitor → HTTP.
2. URL: https://console.minio.example.com (or https://minio.example.com:9001).
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Label: MinIO Console UI.

The console runs as a separate process from the MinIO API server. A console failure doesn't affect API operations, but losing admin access blocks your ability to respond to other failures — so it's worth tracking.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Liveness (/minio/health/live) | Non-200 | MinIO process down; restart the service | | Readiness (/minio/health/ready) | Non-200 | Disk offline or cluster degraded; check disk health and MinIO logs | | SSL certificate | < 30 days to expiry | Renew certificate; update MinIO TLS config | | Bucket probe object | Non-200 or keyword missing | Bucket operations failing; check permissions and storage | | Console UI | Non-200 | Admin console unavailable; check MinIO console process |

Alert after: 2 consecutive failures for bucket probe monitors (transient network issues can cause a single false positive). 1 failure for liveness and readiness monitors — MinIO failures cause immediate data pipeline impact.

Common MinIO Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | MinIO process crash / OOM | Liveness monitor unreachable; alert within 60 s | | Disk offline or unmounted | Readiness monitor returns 503; liveness stays green | | Disk full → storage quota exhausted | Readiness may return 503; bucket probe write fails | | Distributed cluster loses quorum | Readiness returns 503 as drives drop below minimum | | MinIO healing after disk replacement | Readiness returns 503 during healing window | | SSL certificate expires | SSL monitor alerts at 30-day threshold | | Bucket policy change blocks reads | Bucket probe monitor fires; health endpoints stay green | | DNS misconfiguration | All monitors fire simultaneously |

MinIO's built-in health endpoints make monitoring straightforward, but the liveness check alone isn't enough — a running MinIO process with a failed disk will pass liveness while failing to serve requests. Vigilmon's layered monitoring of both endpoints, the bucket probe, and SSL certificates gives you complete visibility into MinIO's health from the outside, catching disk failures and cluster degradation before they cause silent data pipeline failures.

Start monitoring MinIO in under 5 minutes — register free at vigilmon.online.