Modal is the serverless cloud platform optimized for Python and ML workloads — running GPU-accelerated functions, model training jobs, batch inference pipelines, and scheduled data processing without managing infrastructure. When a Modal web endpoint goes down, your API consumers receive errors. When a Modal scheduled function stops running, data pipelines silently stall. When the Modal API itself is degraded, deployments fail and new function invocations are rejected. Vigilmon gives you external visibility into Modal's availability from your users' perspective: endpoint uptime, SSL health, and webhook delivery, before your customers notice.
What You'll Build
- An HTTP monitor on a Modal web endpoint to detect serving failures
- A webhook monitor to track whether Modal's outbound webhook calls are reaching your infrastructure
- An SSL certificate monitor for your custom Modal domain
- An alerting setup that separates endpoint failures from scheduled pipeline failures
Prerequisites
- A Modal account with at least one deployed web endpoint or scheduled function
- A Modal web endpoint URL (either
*.modal.runsubdomain or a custom domain) - A free account at vigilmon.online
Step 1: Understand Modal's Observable Surfaces
Modal is a managed serverless platform — the underlying infrastructure is Modal's responsibility. What you can observe externally:
| Surface | Observable via |
|---|---|
| Web endpoints (@modal.web_endpoint) | HTTP uptime monitoring |
| ASGI apps (@modal.asgi_app) | HTTP uptime monitoring |
| Scheduled functions (@modal.cron) | Heartbeat monitoring (function emits a ping after each run) |
| Outbound webhooks from Modal | Webhook receiver + Vigilmon HTTP monitor |
| Modal API (app management) | HTTP monitoring against api.modal.com |
| Custom domain SSL | SSL certificate monitoring |
External monitoring focuses on your deployed endpoints and any outbound integrations your Modal functions drive.
Step 2: Monitor a Modal Web Endpoint
If you've decorated a Python function with @modal.web_endpoint or @modal.asgi_app, Modal assigns it an HTTPS URL. This URL is the primary observable surface for endpoint health:
# Example Modal web endpoint
import modal
app = modal.App("my-inference-api")
@app.function(gpu="A10G")
@modal.web_endpoint()
def predict(request):
# ... inference logic
return {"result": "ok"}
Modal assigns this a URL like https://your-org--my-inference-api-predict.modal.run.
- Log in to Vigilmon → Add Monitor → HTTP.
- URL: your Modal endpoint URL (e.g.,
https://your-org--my-inference-api-predict.modal.run). - Check interval: 60 seconds.
- Response timeout: 30 seconds (Modal functions cold-start; allow extra time).
- Expected status:
200. - Keyword: a stable string in your response JSON (e.g.,
result). - Label:
Modal inference endpoint. - Click Save.
Cold starts: Modal functions scale to zero when idle. The first request after a period of inactivity triggers a container cold start, which can take 5–30 seconds depending on image size and GPU provisioning. Set the response timeout to 30–45 seconds to avoid false-positive alerts from cold starts.
This monitor catches:
- Modal endpoint crashes or unhandled exceptions returning 500
- Dependency import failures that prevent function execution
- Modal platform-level outages affecting your endpoint
- Custom domain misconfiguration
Alert sensitivity: Set to trigger after 2 consecutive failures to avoid alerting on normal cold-start timeouts.
Step 3: Add a Health Check Route to Your Modal App
Rather than monitoring your production inference route (which may have authentication or expensive GPU usage), add a lightweight health check route:
import modal
app = modal.App("my-inference-api")
@app.function()
@modal.web_endpoint()
def health():
return {"status": "ok", "version": "1.0.0"}
@app.function(gpu="A10G")
@modal.web_endpoint()
def predict(request):
# ... actual inference
pass
Monitor https://your-org--my-inference-api-health.modal.run instead of the GPU endpoint — this keeps monitoring costs low and avoids triggering expensive GPU allocation for health checks.
Step 4: Monitor Scheduled Function Execution with Heartbeats
Modal's @modal.cron decorator schedules functions to run on a cron schedule. Unlike HTTP endpoints, scheduled functions don't return a response you can poll. Use a heartbeat pattern instead:
import modal
import httpx
app = modal.App("my-data-pipeline")
HEARTBEAT_URL = "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"
@app.function(schedule=modal.Cron("*/15 * * * *"))
def run_pipeline():
# ... data processing logic
# Notify Vigilmon on successful completion
httpx.get(HEARTBEAT_URL, timeout=5)
In Vigilmon:
- Add Monitor → Heartbeat.
- Expected interval: 15 minutes (or whatever your cron schedule is).
- Grace period: 5 minutes.
- Label:
Modal pipeline heartbeat. - Copy the generated heartbeat URL into your function code.
- Click Save.
Vigilmon alerts you if the heartbeat URL hasn't been called within the expected interval — meaning your scheduled function silently stopped running, failed every invocation, or hit a Modal quota limit.
Step 5: Monitor a Custom Domain SSL Certificate
If you've assigned a custom domain to a Modal app (using modal.web_endpoint(custom_domains=[...])), monitor the SSL certificate:
openssl s_client -connect api.example.com:443 2>/dev/null | openssl x509 -noout -dates
- Add Monitor → SSL Certificate.
- Domain: your custom Modal domain (e.g.,
api.example.com). - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
Modal manages SSL for
*.modal.runsubdomains automatically. You only need to monitor SSL for custom domains where you're responsible for certificate renewal.
Step 6: Monitor Modal API Availability
If your deployment pipeline calls the Modal API programmatically (e.g., using modal deploy in CI/CD or the Python SDK's modal.runner), monitoring api.modal.com gives early warning of platform-level degradation:
- Add Monitor → HTTP.
- URL:
https://api.modal.com. - Check interval: 2 minutes.
- Response timeout: 15 seconds.
- Expected status: any non-5xx (Modal's root endpoint may return 404 — set expected status to
200,404). - Label:
Modal API availability. - Click Save.
This is a coarse-grained check. For authoritative Modal platform status, subscribe to Modal's status page in addition to this monitor.
Step 7: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action | |---|---|---| | Inference endpoint | Non-200 or keyword missing | Check Modal function logs in the Modal dashboard; verify no unhandled exceptions | | Heartbeat | Silence beyond interval + grace | Check Modal cron job history; verify function didn't hit quota or timeout | | Custom domain SSL | < 30 days to expiry | Renew or update custom domain certificate; re-verify in Modal settings | | Modal API | 5xx or timeout | Platform-level issue; check Modal status page; pause CI deployments |
Alert after: 2 consecutive failures for the inference endpoint (cold-start tolerance). 1 missed heartbeat for the pipeline monitor.
Common Modal Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Modal function raises unhandled exception | Endpoint monitor fires (500 response) | | Cold-start timeout exceeds response timeout | Endpoint monitor fires — increase timeout threshold | | GPU quota exhausted on Modal account | New invocations queue or fail; endpoint monitor may catch 429/503 | | Scheduled function silently stops running | Heartbeat monitor fires after interval + grace period | | Custom domain DNS misconfiguration | SSL and endpoint monitors fire simultaneously | | Modal platform outage | All endpoint monitors fire; check Modal status page | | Dependency import error in container image | Endpoint returns 500 on every invocation; endpoint monitor fires | | Modal API degraded (deploy failures) | API monitor fires; CI/CD deployments blocked | | Custom domain SSL certificate expires | SSL monitor alerts at 30-day threshold | | Function timeout exceeded | Modal returns 504; endpoint monitor fires if 504 not in expected status |
Monitoring ML Pipeline Quality
Vigilmon monitors Modal's availability and your endpoint's HTTP behavior — it doesn't monitor model output quality or data pipeline correctness. For ML-specific observability:
- Model output monitoring: Log prediction confidence scores, output distributions, and drift metrics to a time-series store. Alert when distributions shift beyond a threshold.
- Batch job success rates: Have batch inference jobs write a completion record to a database or emit a metric — monitor that record's recency.
- GPU utilization: Modal's dashboard shows per-function GPU utilization. Unexpectedly low GPU utilization on inference functions can indicate model loading failures or batching issues.
- Latency percentiles: Track P50/P99 inference latency via Modal's built-in metrics or by logging response times in your function and aggregating externally.
Vigilmon catches infrastructure-level failures (endpoint down, heartbeat missed, SSL expired). ML-quality monitoring requires application-level instrumentation.
Modal gives Python and ML teams the ability to run GPU-accelerated workloads with zero infrastructure management — but "serverless" doesn't mean "unmonitorable." Vigilmon gives you external visibility into Modal's observable surfaces: endpoint uptime, scheduled function health, custom domain SSL, and platform availability, so you know the moment your inference API goes down or your data pipeline stops running, before users or downstream systems surface the failure themselves.
Start monitoring Modal in under 5 minutes — register free at vigilmon.online.