Monitoring Serverless Functions: What Changes When You Cannot SSH In
In serverless environments, there is no server to SSH into, no long-running process to attach a monitoring agent to, and no persistent logs to tail. Cold starts, invocation errors, and timeout failures all happen in milliseconds. This changes monitoring from a continuous model to an event-driven one.
Lambda functions, Cloud Run jobs, and Edge functions change the monitoring model entirely. Here is how to get visibility into serverless workloads without traditional agents.
The serverless monitoring model
Traditional monitoring: continuously observe a running process.
Serverless monitoring: observe discrete invocation events.
Key metrics to collect per function: - Invocation count — are functions being called as expected? - Error rate — what % of invocations throw an exception? - Duration (p50/p95/p99) — how long are functions taking? - Throttle rate — are you hitting concurrency limits? - Cold start rate — what % of invocations are cold starts?
External health checks for serverless APIs
If your serverless function exposes an HTTP endpoint, monitor it from outside: ``` AlertsDock → HTTP GET https://api.example.com/health every 1min Expected: 200 OK within 3s ```
This catches cold start timeout failures that internal metrics miss.
Cron job heartbeats for scheduled functions
Scheduled Lambda/Cloud Functions are high-risk. The trigger can silently fail: ```python import urllib.request def handler(event, context): # ... do work ... urllib.request.urlopen('https://alertsdock.com/ping/{uuid}') ```
Add this heartbeat ping at the END of your function, after all work is done. If the ping doesn't arrive on schedule, the function failed.
Timeout monitoring
Functions that time out do not throw catchable exceptions — they just stop. Instrument timeouts explicitly: ```python import signal def timeout_handler(signum, frame): requests.post('https://alertsdock.com/ping/{uuid}/fail', json={'error': 'Function timeout'}) signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(context.get_remaining_time_in_millis() // 1000 - 2) ```
Cost monitoring for serverless
Serverless cost is directly proportional to invocation count × duration × memory. An infinite retry loop in a Lambda costs real money fast. Monitor invocation count anomalies — a 10x spike is both a cost alert and a bug signal.
Feature Guide
Uptime Monitoring
AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.
Read guideAlternative Page
UptimeRobot Alternative
Compare AlertsDock with UptimeRobot for teams that want uptime monitoring plus heartbeat monitoring, status pages, webhook inspection, and per-resource alert routing.
See comparisonMore articles
Frontend Monitoring: Real User Monitoring vs Synthetic Testing
Backend uptime checks miss the browser. Real user monitoring shows you what actual users experience — slow renders, JavaScript errors, and failed resource loads that your API monitors never see.
API Gateway Monitoring: Seeing What Happens Before Your Code Runs
Your API gateway processes every request before it reaches your service. Rate limits, auth failures, and routing errors all happen there — and most teams have zero visibility into them.
Monitoring AI Workloads: LLM APIs, Inference Costs, and Timeout Handling
LLM API calls can take 30 seconds and cost $0.10 each. When they fail, they fail silently in ways traditional monitoring was never designed to catch.