Monitoring SD.Next (vladmandic/automatic) with Vigilmon

SD.Next (GitHub: vladmandic/automatic) is a feature-rich fork of AUTOMATIC1111 Stable Diffusion WebUI that extends support to additional diffusion backends (Diffusers, ONNX, OpenVINO, TensorRT) and multiple model architectures including SD 1.5, SD 2.x, SDXL, SD3, FLUX.1, and AuraFlow. It maintains full API compatibility with AUTOMATIC1111's /sdapi/* REST endpoints while adding multi-backend and multi-architecture capabilities — making it a direct drop-in replacement that runs on the same default port 7860. For power users running complex multi-model pipelines on a remote server, uptime monitoring is essential. Vigilmon gives you web UI availability monitoring, SD API health checks, model discovery heartbeats, and SSL certificate alerts for every SD.Next deployment.

What You'll Set Up

• HTTP uptime monitor for the SD.Next Gradio web UI (port 7860)
• /sdapi/v1/options REST API health monitor confirming the SD API and active model are loaded
• /internal/ping health endpoint monitor for the fastest API-layer check
• SSL certificate expiry alerts for HTTPS SD.Next deployments
• Cron heartbeat for SD.Next model discovery and backend initialization health

Prerequisites

• SD.Next (vladmandic/automatic) installed and running (default port 7860)
• Network access to the SD.Next host from the internet (direct or via reverse proxy)
• A free Vigilmon account

Step 1: Monitor the SD.Next Web UI

SD.Next runs a Gradio-based web interface on port 7860 — the same default port as AUTOMATIC1111. A 200 response on the root path confirms SD.Next is running and the Gradio interface has loaded.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the SD.Next URL: http://your-server-ip:7860 (or your proxied domain https://sdnext.yourdomain.com).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

If you're migrating from AUTOMATIC1111 and SD.Next is a drop-in replacement, update your existing A1111 monitor's URL — the endpoint and expected response are identical.

Step 2: Monitor the /sdapi/v1/options SD API Endpoint

SD.Next maintains full compatibility with AUTOMATIC1111's /sdapi/* REST API. The /sdapi/v1/options endpoint returns a JSON object with model options — a 200 response confirms both the SD API layer is operational and an active model is loaded and ready for inference.

1. Click Add Monitor in Vigilmon.
2. Set Type to HTTP / HTTPS.
3. Enter: http://your-server-ip:7860/sdapi/v1/options
4. Set Method to GET.
5. Set Check interval to 2 minutes.
6. Set Expected HTTP status to 200.
7. Click Save.

Test the endpoint:

curl http://your-server-ip:7860/sdapi/v1/options | jq '.sd_model_checkpoint'
# "flux1-dev.safetensors [abc12345]"

SD.Next's /sdapi/v1/options reflects the currently loaded model architecture, including the selected diffusion backend. If the backend fails to initialize (e.g., an ONNX or OpenVINO backend error), the options endpoint will fail or return an empty model checkpoint.

Step 3: Monitor the /internal/ping Health Endpoint

SD.Next inherits the /internal/ping endpoint from AUTOMATIC1111 — a lightweight API health check that returns {"status":"ok"} with a 200 response. This endpoint has no dependency on the loaded model, making it the fastest way to confirm the Python application layer is running.

1. Click Add Monitor in Vigilmon.
2. Set Type to HTTP / HTTPS.
3. Enter: http://your-server-ip:7860/internal/ping
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Optionally, set Expected response body contains to "status":"ok".
7. Click Save.

Use /internal/ping as your primary uptime signal and /sdapi/v1/options as the deeper model-loaded confirmation. Together they distinguish between "SD.Next is starting up" (ping responds, options 503) and "SD.Next is fully operational" (both respond with 200).

Step 4: SSL Certificate Alerts for HTTPS Deployments

SD.Next users who expose their instance over the internet should run it behind a reverse proxy with TLS. The same nginx configuration used for AUTOMATIC1111 works without modification since SD.Next uses the same port and WebSocket upgrade headers.

Add a certificate expiry monitor for your SD.Next domain:

1. Open the HTTP monitor for your proxied SD.Next domain (created in Step 1).
2. Enable Monitor SSL certificate under the SSL section.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

A sample nginx reverse proxy configuration for SD.Next:

server {
    listen 443 ssl;
    server_name sdnext.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/sdnext.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sdnext.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:7860;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 600s;
    }
}

SD.Next generation times vary significantly by backend — Diffusers with FLUX.1 can take 10–60 seconds per image; keep proxy_read_timeout high to avoid proxy-level timeouts on long generation requests.

Step 5: Heartbeat Monitoring for Model Discovery and Backend Health

SD.Next's multi-backend architecture means model initialization is more complex than standard A1111 — a backend (Diffusers, ONNX, OpenVINO) may fail to initialize even when the Gradio UI and ping endpoint are responding. The /sdapi/v1/sd-models endpoint is the right heartbeat target: it returns an array of available models with their filenames and hashes, confirming SD.Next's model discovery and the active backend are both functioning correctly.

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to 10 minutes.
3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Create a script that polls /sdapi/v1/sd-models and pings the heartbeat when the model list is non-empty:

#!/bin/bash
# sdnext-heartbeat.sh — run via cron every 10 minutes

MODELS_API="http://127.0.0.1:7860/sdapi/v1/sd-models"
HEARTBEAT="https://vigilmon.online/heartbeat/abc123"

response=$(curl -sf --max-time 15 "$MODELS_API")
if [ $? -eq 0 ] && echo "$response" | grep -q '"filename"'; then
    curl -sf "$HEARTBEAT" > /dev/null
fi

Add to crontab:

*/10 * * * * /path/to/sdnext-heartbeat.sh

The /sdapi/v1/sd-models response looks like:

[
  {
    "title": "flux1-dev.safetensors [abc12345]",
    "model_name": "flux1-dev",
    "filename": "/models/Stable-diffusion/flux1-dev.safetensors",
    "hash": "abc12345"
  }
]

An empty array ([]) or connection failure indicates the model directory is inaccessible or the diffusion backend failed to scan and register models. Vigilmon alerts after 10 minutes of missed heartbeats, giving you time to investigate backend initialization logs before users encounter failures.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
2. Set Consecutive failures before alert to 2 on the Gradio UI monitor — SD.Next startup with large models (FLUX.1, SD3) can take 2–5 minutes and generate one or two missed checks before the UI becomes available.
3. On the /internal/ping monitor, set Consecutive failures to 1 — ping failures while the UI partially responds are immediate action items.
4. On the /sdapi/v1/options monitor, set Consecutive failures to 1 — a model API failure means no generation is possible regardless of UI state.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Gradio UI | http://host:7860/ | SD.Next crash, Gradio server failure | | API layer ping | http://host:7860/internal/ping | Python application layer crash | | SD API + model | http://host:7860/sdapi/v1/options | Model load failure, backend init error | | SSL certificate | HTTPS proxied domain | Let's Encrypt renewal failure | | Model heartbeat | /sdapi/v1/sd-models cron | Model discovery failure, empty model list |

SD.Next gives power users multi-backend, multi-architecture Stable Diffusion inference — FLUX.1, SD3, SDXL, and more — all API-compatible with AUTOMATIC1111. With Vigilmon watching the Gradio interface, the SD API stack, the model discovery pipeline, and your SSL certificates, you get the observability layer that keeps your SD.Next instance running reliably across every backend and architecture it supports.