tutorial

Monitoring StackBlitz with Vigilmon

StackBlitz WebContainers run a full Node.js environment in the browser — but project boot latency spikes, npm install failures, preview server unavailability, and WebSocket connectivity breaks silently ruin developer experience. Here's how to monitor StackBlitz availability, boot performance, and preview connectivity with Vigilmon.

StackBlitz is a browser-native development platform built on WebContainers — a technology that runs a full Node.js runtime, file system, and package manager directly in the browser using WebAssembly and Service Workers. Developers open a project URL and get a running dev server, terminal, and editor in seconds without installing anything locally. When StackBlitz project boot latency spikes due to CDN degradation, when npm package install fails because the WebContainer's registry proxy is unreachable, when the preview server inside the WebContainer stops responding, or when the WebSocket connection between the editor and the running process breaks — developers lose their entire development environment with no fallback except waiting and refreshing. Vigilmon gives you external monitoring for StackBlitz platform availability, project boot performance, preview server health, and WebSocket connectivity so you catch developer experience degradation before it costs your team productive hours.

What You'll Set Up

  • StackBlitz platform availability monitoring
  • Project URL accessibility checks
  • Preview server health monitoring
  • WebSocket connectivity verification
  • Package install performance tracking via heartbeats

Prerequisites

  • StackBlitz projects or StackBlitz Enterprise instance you want to monitor
  • For StackBlitz Enterprise: access to the self-hosted instance URL and admin credentials
  • A free Vigilmon account

Step 1: Monitor StackBlitz Platform Availability

For teams using StackBlitz.com, the platform itself is the first dependency. CDN outages, API endpoint failures, or WebContainer asset loading failures make every project unusable simultaneously. Monitor the core platform availability:

  1. In Vigilmon, click Add Monitor → HTTP / HTTPS.
  2. Enter https://stackblitz.com.
  3. Set Check interval to 1 minute.
  4. Set Expected HTTP status to 200.
  5. Click Save.

Add a secondary monitor for the StackBlitz API endpoint:

  1. In Vigilmon, click Add Monitor → HTTP / HTTPS.
  2. Enter https://stackblitz.com/api/health (or your Enterprise instance equivalent).
  3. Set Check interval to 1 minute.
  4. Enable Keyword check and enter ok to verify the health endpoint returns a success response.

For StackBlitz Enterprise deployments, replace stackblitz.com with your self-hosted instance URL (https://stackblitz.your-company.internal). The Enterprise instance exposes its own health endpoint that covers the API server, WebContainer asset serving, and project storage backend.

If you're embedding StackBlitz in a documentation site or developer portal using the StackBlitz SDK (@stackblitz/sdk), monitor the SDK CDN endpoint as well:

  1. In Vigilmon, add an HTTP monitor for https://unpkg.com/@stackblitz/sdk/bundles/sdk.umd.js.
  2. Set check interval to 5 minutes.
  3. Set expected status to 200.

A CDN failure for the SDK asset makes all embedded StackBlitz editors on your documentation site fail to load — and it's an external dependency you otherwise wouldn't know is down until a user reports it.

Step 2: Track Project Boot Performance

StackBlitz project boot involves several sequential steps: loading the WebContainer runtime from CDN, mounting the virtual file system, starting the Node.js process, and running the dev server startup command. The total boot time perceived by a developer ranges from 2 seconds on fast connections with warm CDN caches to 30+ seconds during cold starts or under network degradation. Monitor boot performance with a synthetic probe:

#!/bin/bash
# /usr/local/bin/stackblitz-boot-check.sh
# Requires: curl, jq

HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
PROJECT_URL="https://stackblitz.com/edit/YOUR-PROJECT-ID"
BOOT_THRESHOLD_SECONDS=20

# Check if the project URL is accessible and returns the editor HTML
START_EPOCH=$(date +%s)

HTTP_CODE=$(curl -s -o /tmp/stackblitz-boot-response.html \
  -w "%{http_code}" \
  --max-time "$BOOT_THRESHOLD_SECONDS" \
  --user-agent "VigilmonProbe/1.0 uptime-check" \
  "$PROJECT_URL")

END_EPOCH=$(date +%s)
RESPONSE_TIME=$((END_EPOCH - START_EPOCH))

if [ "$HTTP_CODE" != "200" ]; then
  echo "StackBlitz project URL returned HTTP $HTTP_CODE (expected 200)"
  exit 1
fi

# Verify the response contains WebContainer initialization markup
if ! grep -q "WebContainer\|stackblitz" /tmp/stackblitz-boot-response.html 2>/dev/null; then
  echo "Response missing expected WebContainer content"
  exit 1
fi

if [ $RESPONSE_TIME -gt $BOOT_THRESHOLD_SECONDS ]; then
  echo "Project URL too slow: ${RESPONSE_TIME}s > ${BOOT_THRESHOLD_SECONDS}s threshold"
  exit 1
fi

echo "Project boot OK: ${RESPONSE_TIME}s"
curl -s "$HEARTBEAT_URL"

Replace YOUR-PROJECT-ID with the ID from your StackBlitz project URL. Install the cron job:

chmod +x /usr/local/bin/stackblitz-boot-check.sh
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/stackblitz-boot-check.sh >> /var/log/stackblitz-boot.log 2>&1") | crontab -

The HTTP response time doesn't capture full WebContainer boot time (which requires browser JavaScript execution), but it reliably measures whether the CDN is serving project assets at acceptable latency. A spike from 2 seconds to 15 seconds indicates CDN edge degradation in your region.

Step 3: Monitor Preview Server Availability

When a StackBlitz project boots and runs a dev server (Vite, Next.js, Express, etc.), the preview server is accessible via a project-specific URL (https://PROJECT.stackblitz.io or via the embedded preview frame). For teams that use StackBlitz as part of their development workflow, review apps, or interactive documentation, preview server availability is the primary user-visible health signal.

If your StackBlitz project exposes a preview at a stable URL, monitor it directly:

  1. In Vigilmon, click Add Monitor → HTTP / HTTPS.
  2. Enter your preview URL: https://angular-hello-world.stackblitz.io.
  3. Set Check interval to 2 minutes.
  4. Set Expected HTTP status to 200.
  5. Add a Keyword check for a string that should appear in your app's HTML (e.g., your app's title tag content).

For StackBlitz Enterprise, preview URLs follow a consistent pattern based on your instance domain. If you use vanity preview domains:

#!/bin/bash
# /usr/local/bin/stackblitz-preview-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/def456"
PREVIEW_URLS=(
  "https://your-project-1.stackblitz.your-company.internal"
  "https://your-project-2.stackblitz.your-company.internal"
)

FAILED=0
for url in "${PREVIEW_URLS[@]}"; do
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 15 "$url")
  if [ "$HTTP_CODE" != "200" ]; then
    echo "Preview unavailable: $url (HTTP $HTTP_CODE)"
    FAILED=$((FAILED + 1))
  fi
done

if [ $FAILED -gt 0 ]; then
  echo "$FAILED of ${#PREVIEW_URLS[@]} previews unavailable"
  exit 1
fi

echo "All previews available"
curl -s "$HEARTBEAT_URL"

Note that StackBlitz previews are not always persistently available — they go to sleep when a project hasn't been actively edited. For monitoring purposes, focus on projects that are actively in use (live documentation, review apps, shared development environments) rather than every project in your organization.

Step 4: Verify WebSocket Connectivity

StackBlitz uses WebSocket connections extensively — between the browser-side editor and the WebContainer runtime, between the WebContainer and the preview server, and for real-time collaboration in Enterprise. When WebSocket connectivity degrades (corporate firewalls blocking WSS, proxy misconfiguration, StackBlitz platform issues), the editor appears to load but the terminal hangs, package installs freeze, and the preview never refreshes.

Monitor WebSocket endpoint reachability:

#!/bin/bash
# /usr/local/bin/stackblitz-ws-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/ghi789"

# Test WebSocket endpoint reachability via HTTP upgrade check
# curl's --http1.1 with Upgrade header tests WebSocket reachability
WS_HOST="stackblitz.com"
WS_PORT=443

# Test TCP connectivity to the WebSocket port
NC_RESULT=$(nc -z -w 10 "$WS_HOST" "$WS_PORT" 2>&1)
if [ $? -ne 0 ]; then
  echo "Cannot reach $WS_HOST:$WS_PORT — TCP connection failed"
  exit 1
fi

# Test TLS handshake (WebSocket over WSS requires TLS)
TLS_RESULT=$(echo "" | timeout 10 openssl s_client -connect "$WS_HOST:$WS_PORT" \
  -servername "$WS_HOST" 2>&1)

if ! echo "$TLS_RESULT" | grep -q "CONNECTED"; then
  echo "TLS handshake failed for $WS_HOST:$WS_PORT"
  exit 1
fi

echo "WebSocket endpoint reachable: $WS_HOST:$WS_PORT"
curl -s "$HEARTBEAT_URL"

For StackBlitz Enterprise, the WebSocket endpoint is your self-hosted instance. For StackBlitz.com, the WebSocket connections go to the same domain as the HTTP endpoints — if the HTTP monitors are healthy but WebSocket connectivity fails, it typically indicates a load balancer or proxy configuration issue between your network and the StackBlitz CDN.

If you're embedding StackBlitz in a corporate developer portal and know that WebSocket connectivity is a recurring issue for certain network segments, add a second heartbeat specifically from a probe deployed inside that network segment to catch connectivity issues that only affect your internal users.

Step 5: Track Package Install Performance

npm package install inside WebContainers is a synthetic benchmark for overall WebContainer health — it exercises the Node.js runtime, the network proxy for registry requests, and the virtual file system simultaneously. When any of these degrade, install times grow from 5 seconds to 60+ seconds or fail entirely, blocking project boot for any project with npm install in its startup command.

For teams using StackBlitz Enterprise, you can set up an install performance probe using the StackBlitz CLI:

#!/bin/bash
# /usr/local/bin/stackblitz-install-check.sh
# Requires: node, @stackblitz/sdk (or Playwright for full WebContainer boot)

HEARTBEAT_URL="https://vigilmon.online/heartbeat/jkl012"
INSTALL_THRESHOLD_SECONDS=30

# Use a lightweight probe project that installs a single small package
PROBE_SCRIPT=$(cat <<'EOF'
const sdk = require('@stackblitz/sdk');
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();

  const start = Date.now();
  await page.goto('https://stackblitz.com/edit/your-probe-project-id', {
    waitUntil: 'networkidle0',
    timeout: 60000,
  });

  // Wait for the terminal to show install completion
  await page.waitForSelector('.terminal-output', { timeout: 60000 });
  const elapsed = (Date.now() - start) / 1000;

  await browser.close();

  if (elapsed > THRESHOLD_SECONDS) {
    process.stderr.write(`Install probe too slow: ${elapsed}s\n`);
    process.exit(1);
  }
  process.stdout.write(`Install probe OK: ${elapsed}s\n`);
})();
EOF
)

THRESHOLD_SECONDS=$INSTALL_THRESHOLD_SECONDS

node -e "$PROBE_SCRIPT"
if [ $? -ne 0 ]; then
  exit 1
fi

curl -s "$HEARTBEAT_URL"

For simpler setups without a headless browser, monitor the install performance indirectly: set up a StackBlitz project whose boot command is npm install && node server.js and monitor the preview server endpoint. A boot failure or latency spike captured by the preview monitor (Step 3) will correlate with install performance issues.

Run install performance checks every 15 minutes — they're heavier than simple HTTP checks and should not run on the same interval as uptime checks.

Putting It All Together

With these five monitors in place, your Vigilmon dashboard covers the full StackBlitz developer experience stack:

| Monitor | Type | Check Interval | Alert On | |---------|------|----------------|----------| | Platform availability | HTTP | 1 min | Non-200 response | | Project boot latency | Cron heartbeat | 5 min | Boot > 20s or failure | | Preview server health | HTTP | 2 min | Non-200 or wrong content | | WebSocket connectivity | Cron heartbeat | 5 min | TCP/TLS failure | | Package install performance | Cron heartbeat | 15 min | Install > 30s or failure |

The most critical monitor to set up first is platform availability — a simple HTTP check on stackblitz.com (or your Enterprise URL) that catches total outages in under a minute. Follow it with preview server health for the specific projects your team or users depend on daily.

StackBlitz's WebContainer architecture means there's no server-side process to monitor directly — the "server" runs in the browser. That shifts the monitoring responsibility from process-level health checks to user-experience proxies: can the project page load? Does the preview server respond? Are WebSocket connections reachable? External monitoring with Vigilmon answers all of those questions continuously, giving you the signal you need when the developer experience degrades before your team spends an hour debugging network issues or assuming it's their local setup.

Sign up for a free Vigilmon account and add your first StackBlitz availability monitor in under two minutes.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles