Own your monitoring stack with a public status page and private control plane.
Uptime is a self-hosted monitoring system built for teams that want vendor-free visibility. It runs inside your AWS account, becomes autonomous once deployed, fans out checks across regions, stores history in DynamoDB, starts and stops monitor workflows from its own control plane, and fires SNS notifications to users when status changes happen.
High Level Overview
Built for ownership, not outsourcing.
One management plane, many probe regions
A home-region Lambda serves the status page, admin app, and orchestration logic. On every scheduled run it autonomously discovers enabled hosts, invokes worker Lambdas in each configured region, starts or stops monitoring behavior based on the live configuration, and aggregates the results into a single operational view.
Low-cost by design
The stack is intentionally small: Lambda for compute, DynamoDB for history, EventBridge for cadence, SNS for alerts, and Secrets Manager for admin access.
Multi-region checks
HTTP and TCP probes can run from multiple AWS regions, which helps distinguish service failures from localized routing or regional issues.
Public + private surfaces
Visitors see only the clean public status page. Operators get a separate authenticated admin surface for hosts, settings, retained history, and region deployment.
# Core routes GET /status GET /admin GET /api/hosts POST /api/regions # Checks HTTP + TCP per-host SNS alerts TTL retention in DynamoDB
Infrastructure Walkthrough
How the system is wired.
Step 1
Home region control plane
The management Lambda is the entry point. It serves the public status page, the `/admin` UI, and the authenticated API. The same function is also triggered by EventBridge once per minute to orchestrate checks, so once the stack is up it continues running autonomously.
Step 2
Regional execution
The orchestrator fans out to worker Lambdas deployed in the AWS regions you enable. Those workers execute the actual HTTP or TCP probes from different geographies and return the data needed for aggregation.
Step 3
History and state
Host configuration, region metadata, and current health live in the `uptime-hosts` table. Check history is written into `uptime-checks`, with TTL-based retention so old rows age out automatically.
Step 4
Alerting and access
The admin key is stored in Secrets Manager for the CloudFormation path, while per-host SNS topics can be used for transition alerts. Operators can preview the public page and manage visibility per host directly from the admin UI, while the running system itself handles notifications automatically.
What you can deploy today
CloudFormation is the primary install path and supports a one-click bootstrap flow hosted from `www.maimons.dev` artifacts.
Terraform also exists for repo-driven infrastructure teams and maps the same core building blocks: Lambda, function URL, DynamoDB, Secrets Manager, Route53, and IAM.
The current setup is a strong fit for internal tools, public-facing services, and multi-region health checks where cost transparency and deployment ownership matter.
Screenshots
The page is set up for option 3: a public status surface for visitors, and admin shown through screenshots rather than a public console link. Send a screenshot and I can drop it straight into these slots.
Public Status Page
Placeholder for the live status surface screenshot. Once you share it, I can swap this block for the real image and add a matching caption.
Admin Dashboard
Placeholder for the private admin UI screenshot. This keeps the operator experience visible without exposing a public admin link.