How to Monitor Score Workload Deployments with Vigilmon

Score is an open-source workload specification format developed under the CNCF that lets you describe your service once and deploy it anywhere. A single score.yaml defines your container, its ports, environment variables, and resource dependencies — then Score CLI tools (score-compose, score-k8s) translate that spec into platform-appropriate deployment artifacts.

The portability is the point. But it also means your workload runs on different infrastructure depending on the target, and you need external monitoring to confirm it's healthy after each deployment — regardless of which platform runs it.

In this tutorial you'll set up end-to-end monitoring for Score-deployed workloads using Vigilmon — free tier, no credit card.

Why Score workloads need external monitoring

Score separates the workload definition from the deployment platform. That abstraction is powerful but introduces failure modes that neither Score nor the platform CLI will catch:

• Platform-specific startup failures — a score.yaml translates correctly to Kubernetes manifests, but the resulting pods crash due to resource limits or missing secrets on the target cluster
• Resource provisioner failures — Score declares a postgres or redis resource; the provisioner creates it, but the connection string injected as an env var is wrong
• Port translation errors — Score maps container ports to service ports; the generated Service spec has a wrong targetPort, so traffic never reaches your container
• Environment variable drift — different Score implementations inject variables differently; a variable that works in score-compose may be missing in score-k8s
• Post-deployment drift — the deployment succeeded but a Kubernetes node eviction or cloud maintenance window caused downtime hours later

External HTTP and TCP monitoring from Vigilmon fills the gap — it verifies that the real deployed service is reachable right now, regardless of what the manifest says.

What you'll need

• A Score workload deployed to Docker Compose or Kubernetes
• An externally reachable URL for your workload
• A free Vigilmon account

Step 1: Write your Score spec with a health endpoint

Your score.yaml should declare your service's container and port. Add a health check path if your Score implementation supports it:

apiVersion: score.dev/v1b1
metadata:
  name: my-api

containers:
  main:
    image: my-api:latest
    variables:
      PORT: "3000"
      DATABASE_URL: ${resources.db.connection_string}
    livenessProbe:
      httpGet:
        path: /health
        port: 3000
    readinessProbe:
      httpGet:
        path: /health
        port: 3000
      initialDelaySeconds: 5
      periodSeconds: 10

service:
  ports:
    http:
      port: 80
      targetPort: 3000

resources:
  db:
    type: postgres

Add the /health route to your application:

// Node.js/Express
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok', service: 'my-api' });
});

# FastAPI
@app.get("/health")
async def health():
    return {"status": "ok"}

Step 2: Deploy with your Score implementation

Docker Compose target:

score-compose init
score-compose generate score.yaml
docker compose up --build -d

Kubernetes target:

score-k8s init
score-k8s generate score.yaml
kubectl apply -f manifests/

After deployment, verify the external URL is reachable:

curl -sf https://my-api.example.com/health

Step 3: Set up HTTP monitoring in Vigilmon

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to your health endpoint, e.g. https://my-api.example.com/health
4. Set the check interval to 1 minute
5. Under Expected response, configure:
   • Status code: 200
   • (Optional) Response body contains: "status":"ok"
6. Save the monitor

The monitor is platform-agnostic. When you redeploy the same score.yaml to a different backend — say, migrating from score-compose to score-k8s — the Vigilmon monitor stays the same. Only the backing infrastructure changes, and any issues with the new platform will show up immediately as uptime failures.

Step 4: Monitor Score-provisioned resource dependencies

Score workloads often declare database or cache dependencies. Monitor those resources directly:

1. In Vigilmon, go to Monitors → New Monitor
2. Choose TCP Port as the type
3. Enter the resource hostname and port, e.g. postgres.example.com / 5432
4. Save the monitor

If your Score provisioner injects a bad connection string, your app's HTTP /health endpoint will likely return a 500 or time out — but monitoring the TCP port separately helps you pinpoint whether the database is unreachable or whether the app is misconfiguring the connection.

Step 5: Monitor multiple Score deployment targets

Score is typically used across multiple environments. Add a monitor per environment:

| Environment | Monitor URL | Alert threshold | |-------------|-------------|----------------| | production | https://my-api.example.com/health | 2 failures | | staging | https://staging.my-api.example.com/health | 3 failures | | dev | https://dev.my-api.example.com/health | 5 failures |

Use different alert channels per environment — PagerDuty for production, Slack for staging, email for dev.

Step 6: Configure webhook alerts

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your Slack or PagerDuty webhook URL
3. Assign the channel to your monitors

For Score workflows, it's useful to correlate Vigilmon alerts with Score deployments. If you deploy a new score.yaml and Vigilmon alerts within minutes, the Score translation or provisioner output is the likely cause:

{
  "monitor_name": "my-api /health",
  "status": "down",
  "url": "https://my-api.example.com/health",
  "started_at": "2024-08-20T11:05:00Z",
  "duration_seconds": 240
}

Step 7: Create a status page

1. In Vigilmon, go to Status Pages → New Status Page
2. Add your workload and resource monitors
3. Publish the page

A status page is useful for Score-based platform teams because it gives developers real-time workload health without needing access to the underlying platform (Kubernetes, Docker, or otherwise).

Key metrics to watch

| Metric | What it catches | |--------|----------------| | HTTP response code | Container startup failure, wrong port translation, missing env vars | | HTTP response time | Resource provisioner latency, Kubernetes scheduling delays | | TCP port reachability | Database provisioning failures, wrong connection strings | | Response body content | Partially-working app returning wrong data due to env var injection errors |

Summary

Score lets you write your workload spec once and deploy it anywhere, but the portability means failures can come from the platform translation layer rather than your code. Vigilmon monitors the external result — probing your deployed endpoint from outside the cluster, verifying it responds correctly, and alerting you within 60 seconds when something goes wrong. Set up a monitor in five minutes and let Vigilmon tell you when a Score deployment breaks, regardless of which platform it's running on.