tutorial

Monitoring Winglang Applications with Vigilmon: Cloud Function Health, API Gateway Availability, and SSL Alerts

How to monitor Winglang-built cloud applications with Vigilmon — API endpoint health checks, cloud function availability, HTTP response validation, and SSL certificate alerts.

Winglang (Wing) is a cloud-oriented programming language that lets developers write cloud-native applications — APIs, queues, storage operations, and scheduled tasks — in a single unified syntax that compiles to AWS CDK, Terraform, or runs locally in the Wing Simulator. Teams building with Wing deploy REST APIs backed by AWS Lambda, Azure Functions, or Google Cloud Functions; they define storage buckets, queues, and schedules as first-class language constructs. When a Wing-compiled API Gateway route returns errors, users experience failures. When cloud functions cold-start latency spikes, user-facing endpoints become slow. Vigilmon gives you external HTTP monitoring for every public endpoint your Wing application exposes, regardless of which cloud platform you target.

What You'll Build

  • HTTP monitors on your Wing-compiled API endpoints to detect availability failures
  • Response body validation to catch silent function failures that return 200 but wrong data
  • A latency baseline check to detect cold-start degradation
  • SSL certificate monitoring for your Wing application domain
  • An alerting setup that separates API-layer failures from function-layer failures

Prerequisites

  • A Winglang application deployed to AWS (Lambda + API Gateway), Azure, or Google Cloud
  • At least one public HTTP endpoint exposed by your Wing app
  • A free account at vigilmon.online

Step 1: Understand How Wing Applications Expose Endpoints

Wing applications expose HTTP endpoints through cloud-native API gateways. A simple Wing API looks like:

bring cloud;
bring http;

let api = new cloud.Api();

api.get("/health", inflight (request: cloud.ApiRequest): cloud.ApiResponse => {
  return cloud.ApiResponse {
    status: 200,
    body: Json.stringify({ status: "ok", service: "my-wing-app" }),
  };
});

When compiled and deployed, this creates an AWS API Gateway endpoint (or equivalent on other clouds). The public URL typically follows patterns like:

https://abc123.execute-api.us-east-1.amazonaws.com/prod/health
https://my-app.azurewebsites.net/api/health
https://us-central1-my-project.cloudfunctions.net/health

These public endpoints are what external monitoring should target — they exercise the entire stack from API gateway routing through function invocation and response serialization.

Step 2: Add a Health Endpoint to Your Wing Application

If your Wing application doesn't already have a health endpoint, add one to each API surface:

bring cloud;

let api = new cloud.Api();

// Health check endpoint — minimal logic, fast response
api.get("/health", inflight (request: cloud.ApiRequest): cloud.ApiResponse => {
  return cloud.ApiResponse {
    status: 200,
    headers: { "Content-Type": "application/json" },
    body: Json.stringify({
      status: "ok",
      version: "1.0.0",
    }),
  };
});

// Your actual application routes
api.get("/users", inflight (request: cloud.ApiRequest): cloud.ApiResponse => {
  // ... business logic
  return cloud.ApiResponse { status: 200, body: "[]" };
});

Deploy with wing compile --target tf-aws main.w && terraform apply or wing deploy (if using the Wing Cloud platform). Note the API Gateway URL output from Terraform or the Wing console.

Step 3: Create a Vigilmon HTTP Monitor for Your Wing API

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://abc123.execute-api.us-east-1.amazonaws.com/prod/health (your actual API Gateway URL).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok (from the JSON body {"status":"ok",...}).
  7. Click Save.

This monitor catches:

  • AWS Lambda function deployment failures that cause API Gateway to return 502
  • Wing application crashes during cold starts that return unhandled 500 errors
  • API Gateway configuration drift after Terraform state corruption
  • AWS Lambda concurrency limits causing throttling (returns 429 or 502)
  • Cloud function permission failures (IAM role changes that break function execution)
  • Region-level AWS Lambda service degradation

Alert sensitivity: Trigger after 1 consecutive failure for health endpoints. Wing apps deployed to Lambda have no warm standby — a single failure means users are already affected.

Step 4: Monitor Key Business Endpoints

Wing applications often have user-facing endpoints beyond the health check. Monitoring the most critical ones with keyword validation catches silent failures — cases where the cloud function runs but returns wrong data:

curl https://abc123.execute-api.us-east-1.amazonaws.com/prod/api/status
# Returns: {"app":"my-wing-app","ready":true}
  1. Add Monitor → HTTP.
  2. URL: https://abc123.execute-api.us-east-1.amazonaws.com/prod/api/status.
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ready (validates actual response content, not just HTTP status).
  7. Label: Wing app status API.
  8. Click Save.

API Gateway can return 200 even when the Lambda function crashes, depending on how error responses are configured. Keyword validation catches cases where the function panics and returns {"message":"Internal server error"} with a 200 wrapper.

Step 5: Monitor for Cold-Start Latency

Wing Lambda functions experience cold starts when they haven't been invoked recently. Cold starts can push response times from ~50ms to 3–8 seconds, causing user-visible timeouts. Configure a response timeout that captures latency degradation:

  1. Add Monitor → HTTP.
  2. URL: https://abc123.execute-api.us-east-1.amazonaws.com/prod/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 5000ms (5 seconds — significantly above warm response time but below user-visible timeout).
  5. Label: Wing health (cold-start guard).
  6. Click Save.

The regular 60-second check interval itself acts as a cold-start prevention mechanism — frequent enough pings keep the Lambda warm in most configurations. Use AWS Lambda Provisioned Concurrency if cold starts are unacceptable for your use case, and monitor the warmed endpoint separately.

Step 6: Monitor SSL Certificates

Wing applications deployed through API Gateway use AWS-managed certificates, but custom domain names configured via Route 53 and ACM have expiry dates. If ACM certificate auto-renewal fails (due to DNS validation records being removed or a domain lapse), the custom domain stops working:

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

ACM certificates auto-renew, but only if the DNS validation record still exists in Route 53. If someone cleans up old Route 53 records or migrates DNS to another provider without re-adding the ACM validation record, auto-renewal silently fails. The 30-day Vigilmon alert gives you a month to fix it before users see TLS errors.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Health endpoint | Non-200 or ok missing | Check AWS Lambda console for function errors; check API Gateway logs | | Status API | Non-200 or keyword missing | Business logic failure; check Lambda CloudWatch logs | | Cold-start guard | Timeout > 5s | Sustained cold-start latency; consider Provisioned Concurrency | | SSL certificate | < 30 days to expiry | Check ACM certificate status; verify DNS validation record in Route 53 |

Alert after: 1 consecutive failure for the health endpoint monitor. 2 consecutive failures for business logic monitors (to filter transient function cold-start hiccups).

Common Winglang Application Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Lambda function crash on cold start | Health monitor fires; API Gateway returns 502 | | IAM role permission change blocks Lambda | Function returns 403 or 500; health monitor catches it | | AWS Lambda service degradation in region | All monitors fire simultaneously | | Terraform state corruption breaks redeploy | Existing endpoints still work; new deployments fail — not caught by external monitoring | | API Gateway custom domain certificate expires | SSL monitor alerts at 30 days | | Lambda function timeout set too low | Requests > N seconds return 504; keyword check catches wrong response | | Wing compiler output produces invalid Terraform | Deploy fails; existing endpoints stay up until next deploy — monitor catches immediate breaks | | CloudFront distribution misconfigured (if used) | HTTP monitor fires; TCP check to origin may succeed | | Memory limit on Lambda too low causes OOM | Function returns 502 from Lambda service; health monitor fires |

Winglang lets your team write cloud infrastructure and application logic in a single language, but the deployed artifacts live in cloud provider infrastructure that can fail independently of your code. A Lambda function can be running fine while the API Gateway route is misconfigured. A certificate can expire while the function stays healthy. Vigilmon gives you continuous external visibility into the URLs your users actually hit, so you know the moment your Wing-compiled application becomes unavailable from the outside world.

Start monitoring your Winglang application 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