tutorial

Monitoring Spin (Fermyon) with Vigilmon: Wasm App Health, Component Trigger Latency, SpinKube Status & Runtime Alerts

How to monitor Fermyon Spin applications with Vigilmon — HTTP trigger availability, component health checks, SpinKube deployment status, Fermyon Cloud connectivity, and WebAssembly runtime alerts.

Fermyon Spin is the open-source WebAssembly microservices framework that compiles application components to Wasm and serves them through pluggable triggers — HTTP, Redis pub/sub, cron, and more. Whether you deploy Spin applications to Fermyon Cloud, self-host the Spin runtime on bare metal, or run SpinKube on Kubernetes, the external surface area is the same: HTTP endpoints served by Wasm components that must respond within milliseconds. When a Spin component fails to initialize, returns an unexpected status code, or times out waiting for the Wasm runtime to execute, your application silently degrades. Vigilmon gives you external visibility into every Spin application endpoint: component health, trigger responsiveness, SpinKube deployment readiness, and SSL certificate health across your Wasm microservice fleet.

What You'll Build

  • HTTP monitors on Spin application trigger endpoints to detect component failures
  • A health check probe that confirms Wasm component initialization
  • SpinKube Kubernetes readiness monitoring via the Spin Operator API
  • Fermyon Cloud application availability checks
  • SSL certificate monitoring for custom Spin application domains
  • An alerting setup tuned for the cold-start characteristics of WebAssembly runtimes

Prerequisites

  • A running Spin application with at least one HTTP trigger
  • The application deployed to Fermyon Cloud, SpinKube (Kubernetes), or the Spin runtime on a server
  • Your application's public URL or custom domain
  • A free account at vigilmon.online

Step 1: Understand Spin's HTTP Trigger Architecture

Every Spin HTTP application exposes one or more routes as configured in spin.toml. A minimal Spin app might look like this:

# spin.toml
spin_manifest_version = 2

[application]
name = "my-api"
version = "0.1.0"

[[trigger.http]]
route = "/..."
component = "my-api"

[component.my-api]
source = "target/wasm32-wasip1/release/my_api.wasm"

When deployed, the Spin runtime serves requests on a configured port (default 3000 for local, port 80/443 for Fermyon Cloud, or the port configured in SpinKube's SpinApp CRD). Each HTTP request instantiates the Wasm component, executes the handler function, and returns the response — no persistent process between requests.

You can probe the health of a Spin application with any HTTP request to a configured route:

curl https://my-app.fermyon.app/
# or
curl http://localhost:3000/health

Spin does not include a built-in health endpoint by default — you should add a /health route to your component, or monitor an existing route that returns a predictable response.

Step 2: Add a Health Route to Your Spin Component

Before setting up Vigilmon monitors, add a dedicated /health route to your Spin application. This is the most reliable probe because it exercises the Wasm runtime, confirms the component compiles and initializes correctly, and returns a predictable response.

For a Rust Spin component:

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
    let path = req.uri().path();
    match path {
        "/health" => Ok(Response::builder()
            .status(200)
            .header("content-type", "application/json")
            .body("{\"status\":\"ok\"}")
            .build()),
        _ => handle_main(req),
    }
}

For a TypeScript Spin component:

import { ResponseBuilder } from "@fermyon/spin-sdk";

export const handler: Handler = async (req, res) => {
  if (new URL(req.url).pathname === "/health") {
    res.set({ status: 200 });
    res.send(JSON.stringify({ status: "ok" }));
    return;
  }
  // main handler logic
};

Add the route to spin.toml:

[[trigger.http]]
route = "/health"
component = "my-api"

Redeploy with spin deploy (Fermyon Cloud) or kubectl apply (SpinKube) and verify:

curl https://my-app.fermyon.app/health
# Returns: {"status":"ok"}

Step 3: Create a Vigilmon HTTP Monitor for the Health Route

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://my-app.fermyon.app/health (or your custom domain / SpinKube ingress URL).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok (from the health response body).
  7. Label: Spin app health.
  8. Click Save.

This monitor catches:

  • Wasm component compilation failures after a bad deploy
  • Spin runtime process crashes or OOM kills
  • SpinKube SpinApp entering a failed or degraded state
  • Fermyon Cloud infrastructure issues affecting your application
  • Custom domain or TLS configuration failures
  • Network connectivity issues between Vigilmon and your Spin deployment

Alert sensitivity: 1 consecutive failure. Spin application failures are typically binary — the Wasm component either initializes and responds or fails completely.

Step 4: Monitor Individual Component Trigger Routes

A single Spin application can have multiple components, each serving different routes. Monitor critical application routes independently to distinguish component-level failures from application-wide outages:

# Monitor the API route
curl https://my-app.fermyon.app/api/v1/items

# Monitor the webhook handler
curl -X POST https://my-app.fermyon.app/webhooks/github \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

For each critical route:

  1. Add Monitor → HTTP.
  2. URL: https://my-app.fermyon.app/api/v1/items
  3. Method: GET (or POST with a test body for write endpoints)
  4. Check interval: 2 minutes.
  5. Response timeout: 10 seconds.
  6. Expected status: 200 (or the correct status for that route).
  7. Keyword: a known field in the response JSON.
  8. Label: Spin /api/v1/items.
  9. Click Save.

Cold starts: Spin Wasm components on Fermyon Cloud are warmed for active applications but may have brief cold-start latency after extended inactivity. If your monitor fires intermittently with timeout errors, increase the response timeout to 20-30 seconds for less-active applications.

Step 5: Monitor SpinKube Deployment Readiness (Kubernetes)

When running Spin on Kubernetes via SpinKube (the Spin Operator), the SpinApp CRD manages deployment lifecycle. SpinKube exposes the Spin application through a Kubernetes Service and Ingress, just like any other Kubernetes workload. The most reliable external check is the HTTP endpoint served through the Ingress:

curl https://spin-app.example.com/health

For deeper cluster-level monitoring, the Spin Operator exposes metrics and readiness through standard Kubernetes mechanisms. If you have access to the Kubernetes API server's external endpoint:

  1. Add Monitor → HTTP.
  2. URL: https://spin-app.example.com/health (the SpinApp's ingress URL).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: SpinKube app health.
  8. Click Save.

Also monitor the SpinKube Spin Operator's own health if it's exposed externally:

# Spin Operator metrics endpoint (typically internal, may need port-forward)
kubectl port-forward -n spin-operator svc/spin-operator-webhook-service 9443:443
curl -k https://localhost:9443/healthz

If you expose the Spin Operator's health endpoint via an ingress:

  1. Add Monitor → HTTP.
  2. URL: https://spin-operator.example.com/healthz
  3. Expected status: 200.
  4. Label: SpinKube Operator health.

SpinKube rollout failures: A SpinApp spec change triggers a Wasm module pull and component re-initialization. If the new Wasm binary fails to compile or the image pull fails, the SpinApp enters a Degraded state and the ingress continues serving the old version (or nothing if this is the first deploy). Vigilmon's HTTP monitor on the ingress catches this — if the response changes or disappears, your deploy broke.

Step 6: Monitor Fermyon Cloud Application Availability

For applications deployed to Fermyon Cloud, the platform manages the Spin runtime, Wasm execution, and TLS. Your application URL is https://{app-name}.fermyon.app. Monitor both the health endpoint and the application root:

# Application health
curl https://my-app.fermyon.app/health

# Application root (confirm routing is working)
curl https://my-app.fermyon.app/
  1. Add Monitor → HTTP for the health route (as in Step 3).
  2. Add Monitor → HTTP for the application root:
    • URL: https://my-app.fermyon.app/
    • Expected status: 200
    • Keyword: a known string from your application's root response
    • Label: Fermyon Cloud app root

Fermyon Cloud regional routing: Fermyon Cloud routes requests to the nearest regional deployment. If you observe intermittent failures that clear within a check interval, check the Fermyon Cloud status page for regional issues before investigating your application code.

Step 7: Monitor Spin's Key-Value and Database Triggers

Spin components can subscribe to Redis pub/sub triggers or use built-in key-value stores. While Vigilmon can't directly probe message broker subscriptions, you can expose a health endpoint in any Redis-triggered component that reports its connection status:

// In your Redis-triggered component, add a companion HTTP health endpoint
use spin_sdk::key_value::Store;

#[http_component]
fn health_check(_req: Request) -> anyhow::Result<impl IntoResponse> {
    // Attempt to open the default KV store as a health check
    let store = Store::open_default()?;
    let _ = store.get("__healthcheck")?;
    Ok(Response::builder()
        .status(200)
        .body("{\"kv\":\"ok\"}")
        .build())
}
  1. Add Monitor → HTTP.
  2. URL: https://my-app.fermyon.app/health/kv
  3. Expected status: 200.
  4. Keyword: ok.
  5. Label: Spin KV store health.
  6. Click Save.

This confirms both the HTTP trigger path and the key-value storage backend are reachable from within the Wasm component.

Step 8: SSL Certificate Monitoring

Fermyon Cloud issues and manages TLS certificates automatically for *.fermyon.app domains. For custom domains configured via spin cloud domain add, cert-manager or Fermyon's certificate automation handles renewal. Monitor the SSL certificate on your custom domain:

openssl s_client -connect my-api.example.com:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: my-api.example.com (your custom Spin app domain).
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days.
  5. Click Save.

For SpinKube deployments with cert-manager:

# Check cert-manager certificate status
kubectl get certificate -n default

Spin and HTTP Strict Transport Security: Spin applications served over HTTPS with Strict-Transport-Security headers require valid certificates at all times — if a certificate expires, browsers and API clients will refuse the connection immediately, with no fallback. The 30-day alert window ensures you have time to rotate before expiry causes hard failures.

Step 9: Configure Alerting

In Vigilmon under Settings → Notifications, configure:

| Monitor | Trigger | Action | |---|---|---| | Health route | Non-200 or keyword missing | Check Wasm compilation; spin deploy logs; SpinKube pod events | | API route | Non-200 or unexpected response | Component logic error or downstream dependency failure | | SpinKube Operator | Non-200 | Spin Operator unhealthy; kubectl get pods -n spin-operator | | KV store health | Non-200 | Key-value backend unreachable; check Fermyon Cloud or SpinKube KV config | | SSL certificate | < 30 days to expiry | Renew certificate; check cert-manager events or Fermyon Cloud domain settings |

Alert after: 1 consecutive failure for the health route and API route. 2 consecutive failures for SpinKube Operator and KV store monitors.

Common Spin Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Wasm component fails to compile after deploy | Health monitor fires; returns 500 or connection error | | Spin runtime OOM killed on self-hosted server | All monitors fail simultaneously | | SpinKube SpinApp enters Degraded state | Health endpoint returns 503 or times out | | Fermyon Cloud regional outage | All .fermyon.app monitors fail simultaneously | | Custom domain DNS misconfiguration | All monitors for that domain fail; .fermyon.app monitors stay green | | SSL certificate expires on custom domain | SSL monitor fires at 30 days; browsers reject connections | | Redis trigger connection failure (companion HTTP check) | KV/Redis health monitor fires | | Wasm component cold start timeout | Query monitor fires with timeout; usually self-resolves | | SpinKube Operator webhook certificate expires | New SpinApp deployments fail; operator health monitor fires | | Key-value store quota exceeded | KV health monitor returns error from within the Wasm component |

Spin's WebAssembly architecture delivers sub-millisecond cold starts and near-zero per-request overhead — but when a Wasm component fails to initialize, the failure is instantaneous and complete. There's no gradual degradation, no graceful retry, no half-responding process. Vigilmon gives you the external visibility to know the moment a Spin component becomes unavailable: the HTTP trigger route, the health endpoint, the SpinKube operator, and the SSL certificate, so your team can respond before users encounter errors from your Wasm microservices.

Start monitoring your Spin applications in under 5 minutes — register free at vigilmon.online.

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