tutorial

Serverless Monitoring Guide 2026: Uptime and Availability for Lambda, Functions, and Event-Driven APIs

Serverless architectures eliminate servers — but they don't eliminate the need for monitoring. In some ways they make it harder. Functions are ephemeral, inv...

Serverless architectures eliminate servers — but they don't eliminate the need for monitoring. In some ways they make it harder. Functions are ephemeral, invocations are stateless, and the infrastructure you're depending on is entirely managed by someone else. When something fails, it can fail silently, intermittently, or in ways your internal observability never surfaces.

This guide covers the unique monitoring challenges of serverless applications and explains how to build reliable external availability monitoring for functions, APIs, scheduled jobs, and event-driven backends.

Why Serverless Is Harder to Monitor

Traditional server monitoring is straightforward: your server is either up or it isn't. You check a port. You ping a process. The failure modes are visible.

Serverless monitoring is different in four important ways:

1. Cold starts introduce latency spikes that look like timeouts

When a Lambda function or Cloud Run service hasn't been invoked recently, the platform provisions a fresh container. Depending on runtime, memory configuration, and package size, this cold start can add 200ms to several seconds of latency to the first request. For latency-sensitive endpoints, this means:

  • Your function is technically "working," but users experience timeouts
  • An API Gateway configured with a 3-second integration timeout will 504 on a cold-started function that takes 4 seconds to initialize
  • Cold starts are non-deterministic — your monitoring needs to observe them from the outside, not infer them from CloudWatch

External monitoring catches cold-start-induced failures that internal metrics may mask with averages or exclude as "initialization overhead."

2. Function timeouts create invisible failures

Serverless runtimes enforce hard execution time limits — 15 minutes for Lambda, 3600 seconds for Cloud Run. When a function times out, the invocation terminates without returning a response. Depending on how the failure surfaces:

  • Synchronous invocations return a 500 or 504 to the caller
  • Asynchronous invocations (SNS, EventBridge, SQS) silently fail and may retry or go to a dead letter queue
  • The function's internal metrics show an error, but no user-facing alert fires if you're only watching internal function metrics

External HTTP monitoring catches synchronous timeout failures immediately: the request times out, the probe fails, your team is alerted.

3. Throttling is opaque to users

AWS Lambda throttles at the account-level concurrency limit (default 1,000 per region) and at the function-level reserved concurrency. When throttled, Lambda returns a 429 TooManyRequestsException. Depending on your architecture:

  • API Gateway translates this to a 503 or 429 for the end user
  • The function itself never executes — so function-level metrics record nothing
  • CloudWatch may alert on throttle counts, but only if you've explicitly created that alarm

Vigilmon's external probe will see the 429/503 and alert your team. The user experience is already degraded — you want to know before your users do.

4. Scheduled functions fail silently

Cron-triggered serverless functions — Lambda with EventBridge, Vercel Cron Jobs, Cloudflare Workers Cron Triggers — are among the most commonly overlooked monitoring gaps. If your nightly report generation function fails, EventBridge retries twice and then gives up. No alert fires unless you've explicitly set up error monitoring.

The right pattern for scheduled functions is a heartbeat check, also called a dead man's switch:

  • At the end of a successful function execution, send an HTTP GET to a Vigilmon heartbeat URL
  • Vigilmon expects this ping on a configured schedule (every hour, every day, etc.)
  • If the ping doesn't arrive within the grace period, Vigilmon alerts your team

This catches the full range of scheduled function failures: timeout, exception, throttle, misconfigured trigger, accidental deletion of the function, or changes to IAM permissions that prevent execution.

What to Monitor in a Serverless Application

1. API Gateway endpoint (HTTP monitor)

Your primary user-facing URL — the API Gateway or function URL that end users and client applications call. Monitor the most critical endpoint in your application with an HTTP check that validates:

  • Status code (200, not 5xx)
  • Response body contains expected content (optional but powerful for catching empty responses)
  • Response time within acceptable bounds

Configure your Vigilmon HTTP monitor to probe this URL every minute from multiple regions. A 5-second response time from a normally sub-100ms endpoint is a signal worth alerting on, even if the status code is 200.

2. Health endpoint (if available)

Many serverless API frameworks expose a dedicated /health or /ping endpoint that checks downstream dependencies — database connectivity, external API reachability, cache warmth. If yours does, monitor this endpoint separately. It catches dependency failures before they affect your primary endpoints.

For Next.js API routes, add:

// pages/api/health.js
export default async function handler(req, res) {
  // check DB connection, external APIs, etc.
  res.status(200).json({ status: 'ok', ts: Date.now() })
}

Point a Vigilmon monitor at /api/health. The function invocation itself proves the runtime is healthy; the response body confirms dependencies are reachable.

3. Webhook receiver endpoint (TCP or HTTP monitor)

If your application receives webhooks from payment providers, version control systems, or SaaS integrations, the webhook endpoint must be reachable for your business to function. Monitor the webhook URL with an HTTP monitor targeting the right path. A simple GET returning 200 or 405 (Method Not Allowed) confirms the endpoint is live.

4. Scheduled function heartbeat (Vigilmon heartbeat monitor)

For every scheduled serverless function in your stack, configure a Vigilmon heartbeat monitor:

  1. Create a heartbeat monitor in Vigilmon and copy the ping URL
  2. Add a ping call at the end of your function's success path:
# Python Lambda handler
import urllib.request

def handler(event, context):
    # ... your function logic ...
    
    # Ping Vigilmon heartbeat on success
    urllib.request.urlopen(
        "https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID",
        timeout=5
    )
    return {"statusCode": 200}

// Node.js Lambda handler
const https = require('https')

exports.handler = async (event) => {
  // ... your function logic ...
  
  // Ping Vigilmon heartbeat on success
  await new Promise((resolve) => {
    https.get('https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID', resolve)
  })
  return { statusCode: 200 }
}

If the function fails to complete (timeout, exception, throttle), the heartbeat ping never fires, and Vigilmon alerts within your configured grace period.

Common Serverless Failure Modes and How Vigilmon Catches Them

| Failure Mode | Internal Metrics Visibility | External Monitoring Visibility | |---|---|---| | Cold start timeout (API Gateway 504) | CloudWatch throttle count | ✅ HTTP probe fails | | Lambda throttling (429) | Lambda throttle metric | ✅ HTTP probe gets 429/503 | | Memory exhaustion → OOM | Lambda duration/error metric | ✅ HTTP probe gets 500 | | Scheduled function silently fails | Only if DLQ alerting configured | ✅ Heartbeat ping missing | | Dependency failure (DB, external API) | Only if health endpoint exists | ✅ Health endpoint HTTP probe | | Deployment breaks function package | Lambda error rate | ✅ HTTP probe immediately fails | | IAM permission removed | Lambda access denied errors | ✅ HTTP probe fails | | Custom domain misconfigured | Not visible internally | ✅ External probe to domain |

Vigilmon for Serverless DevOps Teams

The appeal of serverless is reduced operational overhead. Vigilmon fits that model: it's a SaaS monitoring service with no infrastructure to operate. You don't run monitoring servers. You don't configure alerting pipelines. You add a URL and a Slack webhook, and you're covered.

For serverless teams specifically, the Vigilmon feature set maps cleanly to the failure modes above:

  • HTTP monitors catch API Gateway and function URL failures within one minute
  • Heartbeat monitors catch silent scheduled function failures within the configured grace period
  • TCP monitors can be added for any TCP-accessible dependencies (RDS, ElastiCache) if your monitoring machine has network access to those endpoints
  • Multi-region consensus prevents false alerts from transient single-region network issues — common in cloud environments where network paths are non-deterministic

A complete serverless monitoring setup in Vigilmon for a typical application:

  1. HTTP monitor on your primary API endpoint
  2. HTTP monitor on your /health endpoint
  3. Heartbeat monitor for each scheduled function
  4. Webhook alerts to your team's Slack channel or PagerDuty

Total setup time: under 10 minutes.

Summary

Serverless architectures introduce monitoring challenges that traditional server monitoring tools don't anticipate: cold starts, silent scheduling failures, opaque throttling, and function-level failures invisible to infrastructure-level monitoring.

External uptime monitoring — particularly heartbeat monitoring for scheduled functions — is the most reliable way to catch these failure modes before users report them.

Start monitoring your serverless application for free at vigilmon.online — 5 monitors including HTTP, TCP, and heartbeat types, 1-minute check intervals, multi-region consensus alerting, and Slack notifications at $0/month.

Tags: #serverless #aws #lambda #monitoring #devops #uptime #sre #cloudnative #nodejs #python

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