AWS Builder Center
Weekend Annoying Task Challenge: Serverless PingGuard Uptime Monitor

Weekend Annoying Task Challenge: Serverless PingGuard Uptime Monitor

Stop paying for uptime alerts! Learn how to build a serverless website uptime monitor using AWS Lambda, EventBridge, and SES in under 30 minutes.

Founder & Director @ OmniAi Global Solutions | AWS UG Kolkata Leader, AWS Community Builder

TL;DR / Key Takeaways

  • 100% Serverless & Cheap: Automate your website ping checks every 5 minutes using Amazon EventBridge and AWS Lambda. No servers to patch, no expensive monthly SaaS subscriptions.
  • Instant Email Alerts: We use Amazon Simple Email Service (SES) to instantly ping your inbox if your target URL drops a non-200 HTTP status code or times out.
  • Infrastructure as Code: The entire setup is deployed using a single AWS CloudFormation YAML template, keeping your AWS account clean and making deployment a breeze.

Introduction

We’ve all been there. It’s a Friday night, you just pushed a "minor" bug fix to production, and you go to sleep thinking everything is perfectly fine. Fast forward to Saturday morning, your phone is flooded with messages from users because your site has been throwing a 500 Error since 2 AM. The absolute worst feeling, right?
Paying for a basic third-party ping tool just to check if a single URL is alive feels like a total waste of money. It’s a classic annoying task—monitoring your own monitors.
The solution? A bit of weekend building. Instead of burning cash, you can build a highly reliable, completely serverless website uptime monitor using native AWS services that stays comfortably within the AWS Free Tier. Let's walk through how you can set up this automated ping alert system in under half an hour.

The Vision: What Does This App Do?

Serverless Website Uptime Monitoring Flow (PingGuard) by Soumyadeep Mandal
Serverless Website Uptime Monitoring Flow (PingGuard) by Soumyadeep Mandal
The core concept here is simple automation. The Serverless PingGuard is designed to replace those expensive uptime monitoring tools. Its only job is to aggressively watch your target website and scream if something goes wrong.
Instead of keeping a browser tab open and hitting refresh, this system runs quietly in the background on AWS. Every single 5 minutes, an automated trigger fires off. This trigger wakes up a small piece of code that makes a standard HTTP GET request to your website.
If your website responds with a happy 200 OK, the code goes back to sleep. No news is good news. But, if the website times out, crashes, or gives any non-200 HTTP status code, the system immediately formats an error message and fires off a critical alert directly to your verified email address. You get notified before your customers even realize the site is down.

The Architecture: AWS Services Used

Why did I choose AWS for this? Mostly because once you set it up, you never have to think about it again. It scales infinitely and costs practically nothing. Here is the architecture overview of the AWS services doing the heavy lifting:
  • Amazon EventBridge: This is our cron job. We set up an EventBridge rule with a schedule expression of rate(5 minutes). It acts as the heartbeat of the application, invoking our logic on a strict timer.
  • AWS Lambda: The brain of the operation. I used the built-in python3.12 runtime. Lambda handles the actual HTTP ping request using Python's standard urllib.request library. By avoiding external libraries like requests, we don't even need to zip up external packages or Lambda layers. It runs, checks the site, and dies in milliseconds.
  • Amazon SES (Simple Email Service): When things go south, Lambda uses the boto3 SDK to tell SES to send a downtime alert.
  • AWS CloudFormation: To avoid clicking around the AWS console, everything is defined in a single template.yaml file. It provisions the IAM roles, the Lambda function, and the EventBridge rules automatically.
"By keeping the entire stack serverless and relying on standard library functions in Python 3.12, we achieve zero-maintenance infrastructure that runs purely on demand."

How I Built It: Step-by-Step Instructions

Building this required a bit of trial and error, especially around getting IAM permissions right. Here is exactly how I put it together.

Step 1: Handling the SES Email Sandbox Issue

The biggest roadblock right out of the gate is Amazon SES. If your AWS account is new, your SES is in "Sandbox" mode. This means SES will silently fail to send emails unless both the sender and the receiver email addresses are manually verified.
Before doing anything, you have to go to the AWS SES Console, click on Identities, and verify your alert email address. AWS will send a verification link to your inbox that you absolutely must click.

Step 2: Writing the CloudFormation Template & IAM Roles

Security is a priority. I created a scoped IAM execution role.
  • It starts with the basic AWSLambdaBasicExecutionRole so the function can write its logs to CloudWatch.
  • Then, I added an inline policy strictly allowing ses:SendEmail.

Step 3: Coding the Python 3.12 Logic

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
AWSTemplateFormatVersion: '2010-09-09'
Description: >
Website Uptime & Ping Alert system. Provisions a Python 3.12 Lambda function triggered by
EventBridge every 5 minutes to ping a TargetURL and send SES email alerts if down.

Parameters:
TargetURL:
Type: String
.
.
.
.
.
[Code is available in GitHub linked below]
.
.
.
.
.
TargetURL:
Description: Monitored Website URL
Value: !Ref TargetURL

AlertEmail:
Description: Alert Recipient & Sender Email Address
Value: !Ref AlertEmail
The code needs to be lightweight. It pulls two environment variables: TARGET_URL and ALERT_EMAIL. It issues an HTTP GET request with a strict 10-second timeout. If it fails, or if an exception is thrown, it grabs the exact error details and passes them into the ses.send_email function via boto3.

Step 4: Deploying via AWS CLI

Finally, deploying the infrastructure is just a single command in the terminal.
1
2
3
4
5
6
7
aws cloudformation deploy \
--template-file template.yaml \
.
[Code is available in GitHub linked below]
.
--capabilities CAPABILITY_IAM \
--region us-east-1

What I Learned & Final Wrap-Up

Taking on this weekend challenge was a massive productivity boost. What did I learn? Mostly, that relying on standard Python libraries (urllib) instead of external packages drastically simplifies Lambda deployments. I also got a harsh reminder about the SES Sandbox environment—always verify your identities first!
At the end of the day, building your own serverless website uptime monitor isn't just about saving a few bucks a month. It’s about taking control of your infrastructure, understanding how EventBridge orchestrates tasks, and practicing solid Infrastructure as Code principles with CloudFormation.
No more waking up to angry customer emails. Set it, forget it, and let AWS do the monitoring.

Ready to Deploy?

Don't wait for your site to crash. Grab the full source code, CloudFormation template, and deployment instructions right now.

About the Author:
Soumyadeep Mandal is the Director of Omniai Global Solutions and the leader of the AWS User Group in Kolkata, India. When he isn't designing cloud architectures or managing multi-brand e-commerce platforms, he's actively sharing insights with the cloud community online as imsampro.
Connect & Follow:
👉 X (Twitter)     | LinkedIn    | GitHub   

Frequently Asked Questions

1. Does this serverless website uptime monitor cost money?
If you are under the AWS Free Tier, this will cost you $0. EventBridge triggers, 128MB Lambda executions running for a few milliseconds, and SES emails for personal alerts easily fit within the generous monthly free tier limits.
2. Can I monitor multiple URLs with this setup?
The current single-file template takes one TargetURL parameter. However, you can easily modify the Python code to accept a comma-separated list of URLs from the environment variable and loop through them.
3. Why am I not receiving the downtime emails?
99% of the time, this is because your AWS account is in the Amazon SES Sandbox environment. You MUST manually verify your target email address in the SES console before Lambda can send anything. Check your Lambda CloudWatch logs; if it says "Email address is not verified," that's your issue.

Related Reading:
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article