Uptime monitoring for AWS apps
AWS gives you the infrastructure. SitePulse tells you whether users can actually reach it. External 1-minute checks on EC2, ECS, Lambda, ALB, and CloudFront — at $9/mo flat, with a free public status page CloudWatch doesn't offer. Free for 5 monitors.
What CloudWatch doesn't cover
CloudWatch monitors AWS infrastructure: CPU, memory, request count, latency at the load balancer. It's excellent at the metrics layer. What it doesn't do well — without significant Synthetics setup — is tell you whether a real user can reach your app and get a 200 back from your homepage. That's the layer SitePulse handles.
Specific failures CloudWatch alarms typically miss until you build them out:
- A bad deploy starts returning 500s — your ALB is healthy, your app is broken.
- A misconfigured IAM policy breaks one service's access to S3.
- Route53 DNS misconfiguration after a domain change.
- A broken ACM certificate renewal on your CloudFront distribution.
- A Lambda cold start exceeding API Gateway's timeout.
What to monitor on an AWS stack
ALB / public endpoint
Your custom domain in front of an ALB or CloudFront. Catches deploy regressions, ECS/EC2 health failures, and routing issues — exactly as users would experience them.
Lambda Function URL
If you use Lambda Function URLs (or API Gateway), monitor the public URL. Catches function crashes, cold start timeouts, and broken environment variables.
/health endpoint
Add a route that runs a cheap RDS / DynamoDB / S3 check and returns 200 or 503. Catches database degradation, IAM issues, and connection pool exhaustion before user-visible errors.
App Runner / Lightsail
App Runner and Lightsail give you simple HTTPS endpoints. Monitor them directly. Both can experience deploy failures and crashes that aren't surfaced in dashboards immediately.
CloudFront distribution
If you serve content via CloudFront, monitor a specific known URL on the distribution. Catches origin failures, cache invalidation issues, and TLS certificate expiry.
Public status page
Enable SitePulse's free status page. During an AWS regional incident, link customers to your status page so they see real data instead of guessing.
Adding a /health endpoint that exercises AWS dependencies
In a Node.js app on EC2/ECS/Lambda, build a route that touches your critical AWS dependencies:
// Express + AWS SDK example
import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
const ddb = new DynamoDBClient({});
app.get("/health", async (req, res) => {
try {
await ddb.send(
new GetItemCommand({
TableName: "health-check",
Key: { id: { S: "ping" } },
})
);
res.json({ ok: true });
} catch {
res.status(503).json({ ok: false });
}
});Point SitePulse at your custom domain + /health. Now if DynamoDB throttles, IAM credentials rotate incorrectly, or your VPC networking breaks, you find out within one probe interval — not from a customer report.
Set it up in 60 seconds
- Sign up — free, no credit card.
- Add your AWS-hosted custom domain or Lambda Function URL.
- Add /health if you have one, plus any critical API routes.
- Check interval: 5 min on Free, 1 min on Pro ($9/mo).
- Email alert fires the moment any monitor goes red.
What you get
1-minute checks
On Pro plan ($9/mo). No per-canary billing — flat rate covers all monitors.
SSL expiry alerts
Email 14 days before your ACM-managed or third-party certificate expires.
Public status page
Free on every plan. Shareable URL with 30-day uptime history — no extra AWS service needed.
Add monitoring before your next AWS deploy
5 monitors, 5-minute checks, email alerts, public status page — free forever. No credit card.
Frequently asked questions
AWS has CloudWatch Synthetics — why use SitePulse?+
CloudWatch Synthetics is powerful but priced per canary run with a separate bill from your normal AWS spend. It's also configured via Lambda functions, dashboards, and IAM policies — significant setup overhead for what most indie devs need (a 1-minute HTTP check + email alert). SitePulse gives you the same uptime detection in 60 seconds at $9/mo flat, plus a free public status page CloudWatch doesn't offer.
What kind of AWS services can SitePulse monitor?+
Anything with a public HTTP(S) endpoint: EC2 instances behind an ALB or ELB, ECS Fargate services exposed via ALB, Lambda functions with Function URLs or fronted by API Gateway, CloudFront distributions, App Runner services, S3 static website endpoints, Lightsail instances. SitePulse is service-agnostic — it just hits your URL like a real user would.
How do I monitor an internal Lambda or private ALB?+
SitePulse only checks public endpoints. For internal services, the standard pattern is to put a thin public health proxy in front: a small Lambda with a public Function URL, or a dedicated /api/health route on your public app that exercises the internal service and returns 200 or 503. SitePulse monitors the public surface; the surface tells you about the internal state.
How do I detect when RDS or DynamoDB is degraded?+
Don't try to monitor the database directly. Add a /health route to your application that runs a cheap query (SELECT 1 against RDS, a small GetItem against DynamoDB) and returns 200 or 503. Point SitePulse at /health. Now if your DB connection pool exhausts, RDS enters a maintenance window, or DynamoDB hits a throttle, the health route fails and you get an email within one probe interval.
Will SitePulse trigger AWS billing or rate limits?+
Negligibly. One probe per minute is 60 requests per hour from a known IP — far less than a single human user's browsing session. ALB, CloudFront, and Lambda have no problem with this load. The only edge case: if you're monitoring a Lambda Function URL on free tier and have no traffic at all, SitePulse adds ~43,200 invocations per month (still inside Lambda's 1M-invocation free tier).
What's the best URL to monitor — the ALB DNS or my custom domain?+
Always your custom domain. The ALB or CloudFront DNS is stable, but it bypasses the path your real users take — including DNS resolution, certificate validity, and any Route53 routing logic. Monitoring the custom domain catches DNS misconfigurations, expired certificates, and routing failures that a direct ALB probe would miss.