When to Use Serverless: 6 Workloads That Fit [2026]

Event-Driven APIs With Unpredictable Traffic

REST APIs and GraphQL endpoints are the most common serverless workload I see in production. They work well when request rates fluctuate—a webhook receiver that gets 10 requests per hour most days, then 5,000 in ten minutes when a batch import runs.

You pay only for actual request handling time. A function that executes in 200ms costs roughly $0.000000208 per invocation on AWS Lambda with 128MB memory. That same endpoint on a t3.small EC2 instance costs $0.0208 per hour whether it receives zero requests or ten thousand.

The math flips for sustained traffic. If your API serves 100 requests per second continuously, you're paying for 8.64 million invocations per day. At that volume, dedicated compute costs less. Run your actual traffic numbers through a pricing calculator before deciding.

Cold starts matter here. User-facing APIs need sub-second response times, but the first request to a cold function can take 800ms to 2 seconds depending on runtime and dependencies. Test this under real traffic—spin up a load testing tool, send requests after a five-minute idle period, and measure p95 latency.

• Profile your API's request rate over a week to identify traffic patterns
• Calculate break-even point comparing serverless invocation costs to equivalent VM hours
• Test cold start impact by measuring response time after idle periods of 5, 15, and 30 minutes
• Use provisioned concurrency for critical endpoints if cold starts exceed acceptable latency

Scheduled Jobs and Cron Tasks

Scheduled tasks are serverless at its best. A nightly database backup that runs for three minutes shouldn't require a server running 24/7. With serverless, you pay for three minutes of compute time per day.

I've helped customers migrate cron jobs from dedicated instances and cut costs by 95%. A daily report generation job that took eight minutes on a t3.medium instance ($30/month) cost $0.12/month as a Lambda function. The savings compound when you have dozens of scheduled tasks.

Set timeout values carefully based on profiled execution time. If your backup script typically finishes in three minutes, configure a five-minute timeout. When a function times out, it terminates immediately—partial work isn't saved, and you still pay for the execution time.

• Migrate low-frequency scheduled tasks first to validate the approach
• Monitor execution duration over several runs to establish baseline timing
• Configure timeout limits 50-75% above typical execution time
• Set up alerts for timeout events and execution failures

Batch Processing and Data Transformation

Image resizing, video transcoding, log parsing, and CSV processing work well on serverless when the workload is triggered by events rather than running continuously. A function triggers when a file lands in S3, processes it, and writes output back.

Parallel execution is automatic. Upload 100 images and 100 function instances spin up simultaneously, each handling one file. You don't configure autoscaling policies or manage instance pools. This pattern breaks down when processing time exceeds 15 minutes—the maximum execution limit for most serverless platforms.

• Break large files into chunks if processing time approaches timeout limits
• Use queues to coordinate work when output order matters
• Monitor memory usage during processing to optimize function memory allocation
• Test with your largest expected file size to validate timeout and memory settings

Webhooks and Third-Party Integrations

Webhooks from payment processors, Git hosting, and SaaS tools are perfect serverless candidates. You receive a POST request, validate the payload, update your database, and return a 200 response in under a second.

Traffic is completely unpredictable—you might get five webhooks in a minute during a deployment, then nothing for an hour. Running a dedicated endpoint for this costs money during idle time. Serverless eliminates that waste.

Security matters here more than most workloads. Validate webhook signatures before processing, and never trust the payload contents. I've seen production incidents where unvalidated webhook data caused SQL injection because the code assumed the third-party service sent clean data.

• Implement signature verification before processing webhook payloads
• Set strict timeout limits since webhook processing should complete in seconds
• Log full request details for failed webhooks to debug integration issues
• Test error handling—what happens when your function returns a 500 response?

File Processing and Storage Triggers

Functions triggered by file uploads handle workloads like generating thumbnails, extracting metadata, scanning for malware, or converting formats. The pattern is simple: file arrives in object storage, function executes, output is written back.

This eliminates polling. Instead of a background worker checking for new files every 30 seconds, the storage service invokes your function immediately when a file appears. Latency drops and you pay only for actual processing time.

• Configure retry policies for transient failures during processing
• Move large files through presigned URLs rather than passing content in the function payload
• Monitor execution duration per file size to identify performance issues
• Set up dead-letter queues to capture files that fail processing after retries

Background Jobs From Web Applications

When your web app needs to send emails, generate PDFs, or process uploaded data without blocking the HTTP response, offload that work to a serverless function. The web request completes immediately, and the background task runs asynchronously.

I typically see this pattern with queue-triggered functions. The web app pushes a message to SQS or Pub/Sub, returns success to the user, and a function pulls the message for processing. If the function fails, the queue automatically retries.

• Use queues instead of direct function invocation for better failure handling
• Set visibility timeout on queue messages longer than function execution time
• Monitor queue depth to identify backlog issues before users notice
• Implement idempotency—functions may process the same message multiple times on retry

When Serverless Doesn't Fit

WebSocket servers and real-time applications need persistent connections, which serverless doesn't support well. A chat application or multiplayer game backend belongs on traditional compute.

Long-running processes over 15 minutes hit platform limits. Video encoding jobs that take 40 minutes, machine learning training runs, and large data migrations need VMs or container orchestration. Break the work into smaller chunks or choose different infrastructure.

High-throughput sustained workloads cost more on serverless. If your application serves 50 requests per second continuously, calculate the monthly invocation cost—it's usually 2-3x what you'd pay for equivalent dedicated compute. The pay-per-invocation model works for intermittent load, not constant traffic.

Cost Calculation and Testing Approach

Get real numbers before migrating. Profile your workload's execution time, memory usage, and request frequency over a week. Use CloudWatch Logs, application profiling, or server metrics to capture this data.

Plug those numbers into your cloud provider's pricing calculator. AWS Lambda charges per GB-second of memory usage—a function using 512MB for 300ms costs $0.000000625 per invocation. Multiply by your weekly request count to get monthly costs.

Compare that to your current infrastructure costs. Include the hidden costs of traditional hosting—monitoring, patching, autoscaling configuration, and on-call time managing those systems. Sometimes serverless costs more per request but less in operational overhead.

Test cold start impact if you're migrating user-facing APIs. Write a simple script that hits your endpoint after idle periods of 5, 10, and 15 minutes. Measure p50, p95, and p99 latency. If p95 exceeds 1 second, you'll need provisioned concurrency or should reconsider the migration.

Migration Strategy and Rollback Planning

Migrate incrementally. Pick one background job or low-risk API endpoint, move it to serverless, and monitor for a week. Check error rates, execution duration, and cost. If it works, migrate the next component.

Keep your original infrastructure running during migration. Route 10% of traffic to the serverless version, then 25%, then 50%. This gives you real production data without risking full system failure.

Plan your rollback. Document how to route traffic back to the old infrastructure if serverless doesn't work. I've seen teams delete their EC2 instances the day they launch serverless functions, then scramble when cold starts kill their SLA.

Monitor aggressively during the first two weeks. Set up alerts for error rates above 1%, timeout events, and throttling. Track concurrent execution counts to ensure you don't hit account limits during traffic spikes.

Common Production Issues I've Debugged

Database connection exhaustion is the top issue. Each function invocation opens a new database connection. Under load, you quickly hit max_connections limits on Postgres or MySQL. Use RDS Proxy or connection pooling middleware to fix this.

Timeout misconfiguration causes mysterious failures. A function that typically runs in 8 seconds but occasionally needs 12 will intermittently time out. Check CloudWatch Logs for the actual p99 execution time and set timeouts accordingly.

Cold starts hurt more than expected for Python and Java functions with large dependency sets. A Node.js function might cold start in 400ms, while an equivalent Python function with numpy and pandas takes 2.5 seconds. Test your actual runtime before committing.

Concurrent execution limits get hit during traffic spikes. AWS Lambda defaults to 1,000 concurrent executions per region. A sudden traffic burst can exhaust this quota and start throttling requests. Request a limit increase before migration if you expect high concurrency.