CodeSandbox lets teams spin up cloud development environments in seconds — full Linux VMs, persistent branches, and shareable preview URLs that your whole team can access without running anything locally. But when those preview URLs become part of your QA workflow, your stakeholder demos, or your CI/CD pipeline, you need to know when they go down.
In this tutorial you'll set up external uptime monitoring for your CodeSandbox environments using Vigilmon — free tier, no credit card required.
Why CodeSandbox environments need external monitoring
CodeSandbox manages the infrastructure, but it doesn't give you an uptime SLA on preview URLs. Several things can silently take a preview environment offline:
- Sandbox hibernation — CodeSandbox hibernates inactive sandboxes to save resources. A preview URL that QA is checking in the morning may be cold and slow or fully unavailable
- Port exposure failures — when a dev server inside the sandbox crashes or restarts, the port forwarding that exposes it to the public URL may not recover automatically
- Network routing issues — CodeSandbox's ingress layer can have issues that leave your sandbox running but the public URL unreachable
- Branch environment divergence — multiple team members working on different branches may have environments where one is healthy and others are broken; without monitoring you find out from a Slack message, not an alert
- Dependency install failures — automated restores can fail silently, leaving an environment that starts but serves errors
Vigilmon monitors your CodeSandbox preview URLs from multiple geographic regions, independent of whether CodeSandbox's own dashboard shows the environment as "active."
What you'll need
- A CodeSandbox account with a cloud development environment
- A running application that exposes an HTTP endpoint on a public preview URL
- A free Vigilmon account (sign up takes 30 seconds)
Step 1: Set up your dev server and expose a health endpoint
CodeSandbox automatically forwards ports to public preview URLs. First, make sure your application is running and has a /health endpoint.
For a Node.js/Express application:
// src/index.js
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;
app.get('/health', (req, res) => {
res.json({
status: 'ok',
environment: 'codesandbox',
timestamp: new Date().toISOString(),
});
});
app.listen(PORT, () => {
console.log(`Server running on port ${PORT}`);
});
For a Python/FastAPI application:
# main.py
from fastapi import FastAPI
from datetime import datetime
app = FastAPI()
@app.get("/health")
def health():
return {
"status": "ok",
"environment": "codesandbox",
"timestamp": datetime.utcnow().isoformat()
}
Once your server is running, CodeSandbox will show you the preview URL in the preview panel. It typically looks like:
https://abc123-3000.csb.app
Or for CodeSandbox Teams (Boxy):
https://your-project-name-abc123.csb.app
Test that your health endpoint is accessible:
curl https://abc123-3000.csb.app/health
# {"status":"ok","environment":"codesandbox","timestamp":"2024-01-15T10:23:00Z"}
Step 2: Set up HTTP monitoring in Vigilmon
With your preview URL working, add it to Vigilmon:
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS as the monitor type
- Set the URL to your CodeSandbox preview endpoint:
https://abc123-3000.csb.app/health - Set the check interval to 1 minute
- Under Expected response:
- Status code:
200 - (Optional) Response body contains:
"status":"ok"
- Status code:
- Save the monitor
Vigilmon's multi-region consensus prevents false alerts from transient network issues. Multiple probes from different geographic locations must agree the service is down before an alert fires, which is especially useful for CodeSandbox since occasional latency spikes are normal.
Monitoring branch-specific environments
If your team uses CodeSandbox's branch environments feature, each branch gets its own URL. Create separate monitors for branches that need uptime guarantees:
# main branch
https://main-abc123.csb.app/health → Monitor: "csb/main"
# staging branch
https://staging-abc123.csb.app/health → Monitor: "csb/staging"
# feature/checkout branch
https://feature-checkout-abc123.csb.app/health → Monitor: "csb/feature-checkout"
Step 3: Handle CodeSandbox hibernation in your health checks
CodeSandbox hibernates inactive sandboxes after a period of inactivity. When a hibernated sandbox receives a request, it wakes up — but this can take 10–30 seconds.
You have two strategies for handling this with Vigilmon:
Option A: Accept wake-up latency with a longer timeout
In your Vigilmon monitor settings, set a generous response timeout (30–60 seconds). The first check after hibernation may hit the wake-up window; subsequent checks will be fast.
Option B: Keep the sandbox warm with Vigilmon itself
Vigilmon's 1-minute check interval is often enough to prevent hibernation in environments with shorter sleep timers. If CodeSandbox hibernates after 5 minutes of inactivity and Vigilmon checks every minute, the sandbox stays warm.
For environments where hibernation is not acceptable (shared staging, QA environments), configure your devcontainer.json or CodeSandbox configuration to keep processes running:
// .devcontainer/devcontainer.json
{
"postStartCommand": "npm run dev",
"forwardPorts": [3000],
"portsAttributes": {
"3000": {
"label": "App",
"onAutoForward": "openPreview"
}
}
}
Step 4: Configure alert channels
When a preview environment goes down, you want the right people to know immediately.
Email alerts
- In Vigilmon, go to Alert Channels → Add Channel → Email
- Add your team's engineering address or your personal email
- Assign the channel to your CodeSandbox monitors
Webhook alerts for Slack
- Go to Alert Channels → Add Channel → Webhook
- Enter your Slack incoming webhook URL
- Assign the channel to your monitors
Vigilmon sends a structured payload when a monitor goes down:
{
"monitor_name": "csb/staging /health",
"status": "down",
"url": "https://staging-abc123.csb.app/health",
"started_at": "2024-01-15T10:23:00Z",
"duration_seconds": 180
}
You can use this payload to automate recovery actions. For example, a webhook handler that pings the CodeSandbox API to wake the sandbox:
#!/bin/bash
# wake-sandbox.sh — triggered by Vigilmon webhook
SANDBOX_ID="abc123"
curl -s "https://codesandbox.io/api/v1/sandboxes/${SANDBOX_ID}/awake" \
-H "Authorization: Bearer $CSB_API_TOKEN"
echo "Wake request sent for sandbox ${SANDBOX_ID}"
Diagnosing CodeSandbox failures
When a monitor alerts, run through this checklist:
- Check the CodeSandbox dashboard — is the environment shown as active or hibernating?
- Open the terminal in CodeSandbox — run
ps auxto verify your dev server process is running - Check the terminal output — look for crashes, port conflicts, or missing dependencies
- Try the preview URL in a browser — does it load slowly (hibernation wake) or fail immediately (port issue)?
- Restart the dev server —
Ctrl+Cand restart, or usenpm run dev/python -m uvicorn main:app
Step 5: Monitor your API endpoints, not just the health check
If your CodeSandbox environment runs an API that your frontend or mobile app consumes, monitor the actual API endpoints too — not just the health route.
Create additional monitors in Vigilmon for critical paths:
| Monitor | URL | Expected Response |
|---------|-----|-------------------|
| Health check | /health | 200 + "status":"ok" |
| API root | /api/v1 | 200 |
| Auth endpoint | /api/v1/auth/status | 200 or 401 |
For endpoints that require authentication, use Vigilmon's response code monitoring with a wider acceptable range (e.g., accept 200 or 401) so you're testing reachability, not credentials.
Step 6: Create a status page for your team
If your QA team, product managers, or external reviewers depend on CodeSandbox preview environments, give them a status page:
- In Vigilmon, go to Status Pages → New Status Page
- Name it: "Preview Environments"
- Add all your CodeSandbox monitors, grouped by project or team
- Publish the page
Share the status page URL in your team's project README, your Slack channel topic, or your QA process documentation. When someone asks "is the preview URL working?" they can self-serve the answer.
Putting it all together
Here's the recommended monitoring setup for a CodeSandbox team workflow:
| Monitor | Type | What it catches | |---------|------|-----------------| | Main branch health | HTTP | App server crashes, port forwarding failures | | Staging branch health | HTTP | Staging environment degradation | | API endpoint | HTTP | API-level failures independent of health route | | HTTPS port | TCP | TLS and port-level connectivity |
What's next
- SSL certificate monitoring — Vigilmon automatically monitors TLS certificate expiry for HTTPS URLs. CodeSandbox manages certificates, but their renewal can fail on custom domains
- Response time tracking — Vigilmon tracks response time history so you can see if your CodeSandbox environment is getting progressively slower (a sign of memory leaks or dependency accumulation)
- Multi-project coverage — if your organization uses CodeSandbox across multiple projects, create separate Vigilmon monitor groups per project and assign different alert channels to each team
Get started free at vigilmon.online — no credit card, monitors start running in under a minute.