Case Study

WebPing

Cloud-native uptime monitoring · 2025 — Present

Rough draft — replace with the real story: what problem WebPing solves, who it's for, and why you built it instead of using an existing monitor.

FastAPI PostgreSQL Celery + Redis React / Vite Nginx Docker Compose GitHub Actions Gemini API AWS EC2

Overview

WebPing checks a list of URLs on a schedule, flags downtime, and pings the owner. A background worker classifies each failure and drafts a short plain-language incident note using the Gemini API, so a 502 or a timeout reads like a sentence instead of a stack trace.

Placeholder note: swap this for your real motivation — e.g. "I wanted a monitor that explains what broke, not just that it broke."

Architecture

Rough request flow — replace with your actual diagram once deployed.

Scheduler → FastAPI → Celery + Redis → PostgreSQL → Gemini summary → Alert

Key decisions

Celery + Redis for scheduled checks so a slow site never blocks the API server — placeholder, confirm this matches your actual setup.
Postgres over Mongo for uptime history, since the data is relational (site → checks → incidents) — edit if your reasoning differed.
Gemini used only for summarizing already-structured error data, not for the health check itself — replace with your real boundary between LLM and core logic.

Challenges & learnings

Rough placeholder — this is the section recruiters read closest. Write 1-2 real obstacles: a race condition, a flaky check, a cost tradeoff on LLM calls, anything you had to actually debug.

Rough numbers

— sites monitored

— avg check latency

— uptime tracked

Placeholder metrics — fill in once you have real numbers from the deployed instance.

Links

Source code →
Live demo →