tutorial

How to Monitor Garden-Deployed Services with Vigilmon

A practical guide to monitoring Garden (cloud-native developer platform) deployments with Vigilmon — covering Garden server health, deployed service endpoints, API health checks, and environment availability monitoring.

Garden is a cloud-native developer platform that manages the full lifecycle of complex application environments — from local development through staging and CI. It models your entire system as a dependency graph: services, tests, build steps, and tasks, each cached and rebuilt only when inputs change. When you run garden deploy, Garden calculates exactly what needs to change and applies it to your target environment.

But Garden's responsibility ends at deployment. Once your services are running in a Garden-managed environment, you need external visibility into whether they're actually healthy — whether endpoints return expected responses, whether the Garden daemon itself is reachable, and whether environment availability meets your team's expectations. Vigilmon provides that external layer.

What Garden Cannot Tell You

Garden tracks build and deploy state with impressive precision. It cannot report:

  • Whether a deployed service's public endpoint returns 200 from outside the cluster
  • Whether environment-specific DNS resolves correctly after a Garden environment is brought up
  • Whether the Garden API server is reachable for team members or CI runners that depend on it
  • Whether a cached build artifact, when deployed to a new environment, behaves correctly under external traffic
  • Whether latency degraded after a dependency was updated in the Garden graph

These questions are answered by monitoring, not by the developer platform. Garden and Vigilmon are complementary: Garden manages the graph of your system; Vigilmon watches the edges of your system from the outside.

What You'll Set Up

  • HTTP monitors for Garden-deployed service endpoints
  • Garden API server availability monitoring
  • Environment health checks across multiple Garden environments
  • Alert routing for your development and staging teams

You'll need a free Vigilmon account — no credit card required.

Step 1: Configure Health Endpoints in Your Garden Services

Garden services are defined with garden.yml files. Add a health endpoint to each service and reference it in your Garden config so Garden can confirm readiness before marking a deploy complete.

// main.go — Go example
package main

import (
    "encoding/json"
    "net/http"
    "os"
    "time"
)

var startTime = time.Now()

func healthHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]interface{}{
        "status":         "ok",
        "service":        os.Getenv("SERVICE_NAME"),
        "environment":    os.Getenv("GARDEN_ENVIRONMENT"),
        "uptime_seconds": time.Since(startTime).Seconds(),
    })
}

func main() {
    http.HandleFunc("/health", healthHandler)
    http.ListenAndServe(":8080", nil)
}

Reference the health check in your garden.yml:

# garden.yml
kind: Module
type: container
name: my-api
description: My API service

services:
  - name: my-api
    ports:
      - name: http
        containerPort: 8080
    ingresses:
      - path: /
        port: http
    healthCheck:
      httpGet:
        path: /health
        port: http

tests:
  - name: unit
    args: [npm, test]

Garden uses the healthCheck field to verify that a deployment is complete before considering the deploy action done. Vigilmon monitors the same path from outside — but continuously and from multiple locations, not just once on deploy.

Step 2: Monitor Garden-Deployed Service Endpoints

Once your Garden environment is deployed and services are exposed via Ingress or LoadBalancer, configure Vigilmon monitors for each:

  1. Log in to vigilmon.online and go to Monitors → New Monitor
  2. Choose HTTP / HTTPS
  3. Set the URL to the external endpoint of your service: https://my-api.staging.yourdomain.com/health
  4. Check interval: 1 minute
  5. Expected response:
    • Status code: 200
    • Body contains: "status":"ok"
    • Response time threshold: 2500ms
  6. Save

Multi-Environment Monitoring

Garden is designed for multiple environments. Create dedicated monitors per environment so you can see environment-specific health at a glance:

| Monitor Name | URL | Garden Environment | |---|---|---| | [local] my-api | https://my-api.local.yourdomain.com/health | local | | [staging] my-api | https://my-api.staging.yourdomain.com/health | staging | | [preview] my-api | https://my-api.preview.yourdomain.com/health | preview | | [ci] my-api | https://my-api.ci.yourdomain.com/health | ci |

Group all monitors for a single environment into a Vigilmon status page so your team has a shared view of environment health.

Step 3: Monitor Garden Server Health

The Garden daemon (formerly Garden Enterprise) exposes an HTTP API that Garden CLI clients connect to. If you run a shared Garden server for your team or in CI, monitoring it is essential — a down Garden server blocks all deployments.

Garden's server exposes a health endpoint at /health:

# Verify Garden server health
curl https://garden-server.yourdomain.com/health

Set up a Vigilmon monitor for it:

  1. Go to Monitors → New Monitor → HTTP / HTTPS
  2. URL: https://garden-server.yourdomain.com/health
  3. Check interval: 2 minutes
  4. Expected response: status code 200
  5. Name: garden-server
  6. Save

Add a Vigilmon SSL monitor for the same domain to catch certificate expiry:

  1. Go to Monitors → New Monitor → SSL Certificate
  2. Domain: garden-server.yourdomain.com
  3. Alert threshold: 30 days before expiry
  4. Save as garden-server-ssl

Step 4: API Health Checks for Garden-Managed APIs

Garden environments often include multiple API services that communicate with each other. Beyond monitoring each service externally, you want to confirm that the inter-service API relationships are healthy.

Adding API-Specific Health Checks

Extend your health endpoints to verify downstream dependencies:

// src/health.ts
import axios from 'axios'

interface HealthCheck {
  status: 'ok' | 'error'
  latency_ms?: number
  error?: string
}

async function checkDownstream(url: string): Promise<HealthCheck> {
  const start = Date.now()
  try {
    await axios.get(url, { timeout: 3000 })
    return { status: 'ok', latency_ms: Date.now() - start }
  } catch (err: any) {
    return { status: 'error', error: err.message }
  }
}

export async function getHealthStatus() {
  const [userService, cacheService] = await Promise.all([
    checkDownstream(process.env.USER_SERVICE_URL + '/health'),
    checkDownstream(process.env.CACHE_SERVICE_URL + '/ping'),
  ])

  const allOk = userService.status === 'ok' && cacheService.status === 'ok'

  return {
    status: allOk ? 'ok' : 'degraded',
    dependencies: {
      user_service: userService,
      cache_service: cacheService,
    },
  }
}

This means a Vigilmon alert on [staging] order-service with a body check for "status":"ok" will also catch cases where order-service itself is up but a dependency it checks is broken — all visible in a single monitor response.

Monitoring API Rate Limits and External APIs

If your Garden-deployed services call external APIs (payment providers, auth providers, etc.), add TCP or HTTP monitors for those dependencies:

  1. Go to Monitors → New Monitor → HTTP / HTTPS
  2. Add monitors for critical external API status pages
  3. Name them [dep] stripe, [dep] auth0, etc.
  4. Group them with your service monitors in a single status page

When an incident fires, you'll know within seconds whether it's your service or a dependency.

Step 5: Environment Availability Monitoring

Garden environments can be ephemeral — spun up for a PR, torn down after merge. For persistent environments (staging, preview), you want to know if the environment goes unreachable outside of planned maintenance.

Heartbeat Monitoring for Garden CI Pipelines

When Garden runs in CI (garden test, garden deploy --env=ci), wrap the pipeline with a Vigilmon heartbeat:

  1. Go to Monitors → New Monitor → Heartbeat
  2. Name: garden-ci-pipeline
  3. Expected interval: 1 day
  4. Grace period: 3 hours
  5. Save — copy the ping URL
# .github/workflows/garden-ci.yml
name: Garden CI

on:
  push:
    branches: [main]

jobs:
  garden-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Garden
        run: curl -sL https://get.garden.io/install.sh | bash

      - name: Deploy to CI environment
        run: garden deploy --env=ci
        env:
          GARDEN_AUTH_TOKEN: ${{ secrets.GARDEN_AUTH_TOKEN }}

      - name: Run tests
        run: garden test --env=ci

      - name: Notify Vigilmon
        if: success()
        run: curl -fsS "${{ secrets.VIGILMON_HEARTBEAT_URL }}" > /dev/null

If CI fails — whether due to a Garden error, a test failure, or a deploy timeout — the heartbeat ping never fires. Vigilmon alerts after the grace period, telling you that CI has gone silent.

Step 6: Alert Configuration

Slack Integration for Development Teams

Route Garden environment alerts to a dedicated Slack channel so developers know immediately when staging is down:

  1. Create a Slack incoming webhook for #env-alerts
  2. In Vigilmon, go to Alert Channels → New Channel → Webhook
  3. Paste the Slack webhook URL
  4. Assign to all staging and shared environment monitors

Alert Priority by Environment

Not all Garden environments are equal. Configure different alert routing based on severity:

  • Production services: Alert immediately, all channels
  • Staging/preview: Alert to #dev-alerts with a 2-minute delay (avoid alerting on brief restarts)
  • CI environment: Alert only on heartbeat failures (not transient endpoint checks)
  • Local development: No external monitoring needed

Vigilmon supports per-monitor alert channels, so you can implement this routing with a single account.

Summary

Garden manages the complexity of cloud-native development environments with dependency graphs, caching, and reproducible deployments. Vigilmon monitors what those deployments produce — external availability, endpoint health, and environment continuity.

| Concern | Tool | Coverage | |---|---|---| | Build and deploy graph | Garden | Dependency-aware build and deploy | | Readiness detection | Garden healthCheck | In-cluster readiness | | External endpoint health | Vigilmon HTTP monitor | Full external path | | Garden server health | Vigilmon HTTP monitor | API server availability | | SSL certificate health | Vigilmon SSL monitor | Certificate expiry | | CI pipeline continuity | Vigilmon heartbeat | Deploy cadence | | Dependency service health | Vigilmon HTTP/TCP monitor | External dependency health |

Start monitoring your Garden environments for free at vigilmon.online — setup takes under five minutes and gives your team immediate visibility into every environment Garden manages.

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