Uptime Kuma is a self-hosted, open-source uptime monitoring application that periodically checks the availability and response time of services (HTTP, TCP, DNS, databases, Docker containers, and many more) and sends alerts via 90+ notification providers. The system is a monolithic Node.js/Express backend with a Vue 3 SPA frontend, using Socket.IO for real-time updates and SQLite or MariaDB for persistence. It provides status pages, maintenance windows, certificate/domain expiry monitoring, and a Prometheus metrics endpoint. The architecture follows a plugin pattern for monitor types and notification providers, both built on base classes, and includes a condition evaluation system for advanced alerting logic. The codebase is well-structured with clear separation of concerns, extensive tests (unit, integration, e2e), and active community contributions.
OpenStatus is a production-grade, self-hostable uptime monitoring, incident management, and status page platform. In production, it runs multi-region synthetic checks (HTTP, TCP, DNS, ICMP, gRPC) from Go-based checker and private-location services, streams check results into Tinybird for time-series analytics, persists workspace state (monitors, pages, incidents, API keys, OAuth clients) in SQLite via Drizzle ORM, and renders results through a Next.js dashboard and a public, i18n-enabled status page app with custom-domain proxy support, password/email/IP access gating, themes, and RSS/JSON/markdown feeds. A Hono-based API server exposes three API surfaces - a frozen legacy REST v1 (OpenAPI), tRPC, and ConnectRPC - plus an MCP server for AI agents and a Slack bot that can resolve incidents conversationally. The architecture is a deliberately polyglot monorepo: 8+ apps (dashboard, status-page, web marketing, Hono server, Go checker, Go private-location, Deno workflows, Go ssh-server) and 20+ internal packages. Business logic is centralized in packages/services behind a consistent ServiceContext + withTransaction + requireScope + emitAudit mutation pattern, then adapted to tRPC, ConnectRPC, and REST entry points. Multi-tenant workspaces include plan-based limits, API keys with scopes, a full OAuth 2.0 authorization server (PKCE), WorkOS SSO, Stripe billing, and append-only audit logging. Background Deno workflows handle cron maintenance: outbox draining, status drift repair, OAuth client pruning, and uptime freezing. Craftsmanship is strong: the service-layer pattern is applied uniformly, there is an explicit ServiceError hierarchy mapped to both tRPC and gRPC errors, external services (Upstash, Tinybird, Slack, analytics) have thorough test doubles, and several packages are genuinely standalone and reusable (CDN header analysis, assertion engine, schema-driven data-table filters, Effect-based status fetchers). Caveats are real but not disqualifying: the REST v1 API is explicitly frozen and bypasses the service layer, identical composition/chart utilities are duplicated across dashboard and status-page apps, a deprecated screenshot-service remains in-tree, the Go/TypeScript protobuf boundary requires manual synchronization, and an in-progress auth migration has left Clerk-era references alongside NextAuth. Overall this is a well-architected, actively maintained codebase that does what it claims.
Vigil is a microservices status page application written in Rust. It monitors distributed infrastructure services via multiple probe modes (HTTP, TCP, SSH, ICMP, push, script, local), aggregates their health status, and serves a public status page with real-time updates. It also sends alerts through various channels (Slack, Email, Twilio, Telegram, etc.) when services go down or recover. The architecture is a single binary with separate threads for probing, aggregation, and HTTP serving, using a shared in-memory state protected by RwLock. The codebase is well-structured, with clear separation of concerns: config reader, prober, notifier, aggregator, and responder modules. It includes an MCP server for AI agent integration. The project is actively maintained with recent commits and CI/CD pipelines.
This repository implements a static site that reconstructs and visualizes GitHub's historical status incidents and downtime. It ingests the official GitHub Status history Atom feed (committed into git via Flat Data), parses entries into structured incident timelines with status transitions, downtime windows, and impacted components. The frontend displays a 90-day and all-time uptime overview, per-service uptime bars, an incident timeline with filters, and a rolling uptime chart. The system is designed as a data pipeline: a GitHub Action fetches the Atom feed daily, another Action runs the extractor script to produce parsed artifacts (CSV, JSONL), and a third Action deploys the static site to GitHub Pages. The repository also includes an experimental GLiNER-based component extraction fallback to infer affected services from incident postmortems when the structured data is missing. The codebase demonstrates strong craftsmanship with well-isolated pure functions, testable frontend modules, and defensive caching patterns, though it remains tightly coupled to GitHub's specific status page format and prose patterns.
This repository is a curated, structured dataset of C and C++ standard features (from C99 to C++29) with per-compiler support status across multiple toolchains (GCC, Clang, MSVC, Xcode, etc.). It includes YAML data files defining features, toolchain releases, and frontend metadata, along with a C++ validation tool that enforces schema compliance and semantic consistency (e.g., verifying that referenced tool versions exist and issue trackers are properly used). The dataset is designed to power a reference website (cppstat) and is accompanied by detailed Markdown explanations for each feature. While the primary artifact is the data itself, the validator and CI pipeline demonstrate strong data engineering practices, making the repository a reliable source for compiler feature support information.
This is a full-stack SaaS application for cron job monitoring (cron-job.org). It consists of a React frontend (Material-UI, Redux, i18n), a PHP REST API, a C++ execution daemon named 'Chronos', a WAF validator, and a public status page SPA. The system uses Apache Thrift for inter-service RPC, MySQL for job definitions and user data, per-user SQLite databases for historical execution logs, and Redis for rate limiting. The Chronos daemon implements an efficient async HTTP executor using libcurl, libev, and c-ares, with Prometheus metrics exposure. The codebase is production-grade with features like MFA (TOTP/Yubico), API keys, subscription billing (Stripe/Paddle), status pages with custom domains, and comprehensive i18n. However, it shows signs of technical drift: the frontend uses the deprecated Material-UI v4, password hashing is weak (SHA1+MD5), and the Thrift auto-generated code is fragile. The architecture is well-documented and the core execution engine is highly optimized, but the overall codebase would benefit from modernization of the frontend and authentication layers.
Upstat is a self-hosted, open-source status monitoring and uptime tracking tool. The system consists of a Go (Fiber v2) backend API and a Next.js 15 web dashboard, deployed via Docker Compose with support for both PostgreSQL and SQLite databases. The backend periodically pings configurable HTTP endpoints, records heartbeats, calculates uptime percentages, and manages incidents triggered by status transitions. It integrates with multiple notification channels (Discord, Slack, Telegram, Ntfy, Gotify) and provides public status pages with real-time latency charts. The frontend uses shadcn/ui components, React Hook Form with Zod validation, and a custom client fetch wrapper for authenticated API calls. The monorepo also includes a documentation site (Fumadocs) and a static landing page. While the architecture is well-structured with clear separation of concerns (controllers, routes, models, utils), the codebase shows signs of technical drift including outdated dependencies, hardcoded secrets in Docker Compose files, committed SQLite database artifacts, and documentation inconsistencies between the manual API docs and generated OpenAPI spec. The project is functional and suitable for small to medium deployments but would benefit from dependency updates and cleanup before production use.