How to Monitor Finch Containerized Services with Vigilmon

Finch is AWS's open-source container development tool — a CLI for building, running, and managing containers on macOS and Windows using a lightweight Lima VM under the hood. Teams use Finch to develop and test containerized services locally before deploying to Amazon ECS, EKS, or Lambda. But when those containerized services go down in production, Finch itself won't tell you.

In this tutorial you'll add external uptime monitoring to services built and deployed with Finch using Vigilmon — free tier, no credit card required.

Why monitor Finch containerized services?

Finch is used to build and test OCI-compliant container images locally and push them to registries for deployment to AWS. Once those containers are running in production, the standard failure modes apply:

• Container crash loops — the containerized service exits silently under load, and the orchestrator restarts it repeatedly without any external alert
• Image build drift — a Finch-built image pushed from a developer's machine differs from the CI-built image in a way that causes runtime failures
• Port binding failures — the container starts but fails to bind the expected port due to a misconfigured EXPOSE or host networking issue
• Health check misconfiguration — AWS ECS or EKS reports the container healthy while the application layer is returning errors

Vigilmon monitors from outside your infrastructure, giving you an objective signal that is independent of what Finch, ECS, or Kubernetes reports about container health.

What you'll need

• A containerized service built with Finch that exposes an HTTP or TCP endpoint
• A free Vigilmon account

Step 1: Add a health endpoint to your containerized service

Give Vigilmon something reliable to check. Add a /health route to your containerized application:

// Node.js / Express
app.get('/health', (req, res) => {
  res.json({
    status: 'ok',
    container: process.env.HOSTNAME || 'unknown',
    uptime: process.uptime()
  });
});

# Python / FastAPI
@app.get("/health")
def health():
    import socket, time
    return {
        "status": "ok",
        "container": socket.gethostname(),
        "uptime": time.process_time()
    }

// Go
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    hostname, _ := os.Hostname()
    w.Header().Set("Content-Type", "application/json")
    fmt.Fprintf(w, `{"status":"ok","container":"%s"}`, hostname)
})

Including the container hostname makes it easy to identify which container instance is responding — useful when multiple replicas are running behind a load balancer.

Step 2: Add a HEALTHCHECK to your Dockerfile

Define a Docker/OCI HEALTHCHECK instruction so Finch and container orchestrators also report health:

FROM node:20-alpine

WORKDIR /app
COPY . .
RUN npm ci --omit=dev

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=10s --start-period=15s --retries=3 \
  CMD wget -qO- http://localhost:3000/health || exit 1

CMD ["node", "server.js"]

Build and test the health check locally with Finch before pushing to production:

finch build -t my-api:latest .
finch run -d -p 3000:3000 --name my-api my-api:latest

# Wait for the start period, then check
finch inspect --format='{{.State.Health.Status}}' my-api
# Expected: healthy

The HEALTHCHECK instruction gives Vigilmon a consistent target even when containers are replaced or rescheduled.

Step 3: Set up HTTP monitoring in Vigilmon

Once your containerized service is running at a publicly reachable URL, point Vigilmon at the health endpoint:

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

Vigilmon checks from multiple regions every minute. A timeout or non-200 response opens an incident immediately — even if the container orchestrator reports the container as running.

Step 4: Add TCP port monitoring for non-HTTP containers

Finch-built images often include non-HTTP services — message queue consumers, gRPC servers, Redis sidecars. Add a TCP monitor for any port your container exposes:

1. Go to Monitors → New Monitor
2. Choose TCP Port
3. Enter your server hostname and port, e.g. worker.example.com / 6379
4. Save

If the container crashes or the port stops responding, Vigilmon fires an alert within a minute — regardless of what ECS or Kubernetes reports about the pod/task status.

Step 5: Track key metrics

| Metric | What it catches | |---|---| | HTTP response code | Application crash, bad image deploy, port binding failure | | HTTP response time | Performance regression from image change or resource constraint | | TCP port reachability | Container exit, port binding failure, networking misconfiguration | | Response body container field | Wrong container image version running in production |

Vigilmon stores response time history automatically. Set a threshold alert (e.g. alert if response time > 2 s) to detect resource contention or performance regressions after a container image update.

Step 6: Add a heartbeat monitor to your CI/CD build pipeline

Finch is used in CI to build and push container images before deployment. When an ECR push fails or a deployment rollout hangs, your containers never update. Add a Vigilmon heartbeat to your pipeline:

1. In Vigilmon, go to New Monitor → Heartbeat
2. Name it CI Container Build — main
3. Set the expected interval to your CI frequency (e.g. 1 hour)
4. Copy the ping URL

In your GitHub Actions workflow:

- name: Build container image with Finch
  run: |
    finch build -t $ECR_REGISTRY/$IMAGE_NAME:$GITHUB_SHA .
    finch push $ECR_REGISTRY/$IMAGE_NAME:$GITHUB_SHA

- name: Deploy to ECS
  run: |
    aws ecs update-service \
      --cluster production \
      --service my-api \
      --force-new-deployment

- name: Ping Vigilmon — build and deploy succeeded
  if: success()
  run: |
    curl -fsS -X POST "${{ secrets.VIGILMON_FINCH_HEARTBEAT_URL }}" \
      --max-time 10 --retry 3

If the Finch build fails or the ECS deployment errors, no ping is sent and Vigilmon alerts after the grace period.

Step 7: Configure alert channels

1. Go to Alert Channels → Add Channel
2. Choose Email or Webhook (Slack, Discord, PagerDuty)
3. Assign the channel to your HTTP and TCP monitors
4. Set the alert trigger to 1 failed check for immediate notification

When a service goes down:

🔴 DOWN: api.example.com/health
Duration: 4 minutes
Last response: connection refused

When it recovers:

✅ RECOVERED: api.example.com/health
Downtime: 4 minutes

Step 8: Create a status page for your containerized services

If your team runs multiple containerized services built with Finch, a status page surfaces all of them in one view:

1. Go to Status Pages → New Status Page
2. Name it (e.g. "Container Services Status")
3. Add all HTTP and TCP monitors for each container service
4. Publish and share the URL with your team

Team members can check which container is down before filing a bug, and on-call engineers get a single dashboard view across all Finch-built services.

Conclusion

Finch makes it easy to build and test OCI-compliant container images locally before deploying to AWS. Vigilmon ensures those containers are actually serving healthy traffic in production. Together they close the gap between "the image built successfully" and "the service is responding correctly." Add a HEALTHCHECK to your Dockerfile, set up a one-minute Vigilmon HTTP monitor, and add heartbeat monitoring to your CI/CD pipeline — you'll have full container observability in under ten minutes.

Get started free at vigilmon.online.