Back to work
Case Study2024Open Source Concept Build

Ops status console

Lightweight internal console for deploy health and incident visibility during handoffs.

Project Spec Sheet

Timeline
2024
Platform
Next.js
Primary Technologies
Next.jsPostgreSQLJWT AuthTailwind
Ops status console screenshot

The Challenge & Problem

Ops metrics and incident states were fragmented across chat logs and alerts. Engineers had no single dashboard to quickly scan deployment status or audit previous downtime incidents.

Execution & My Role

Built secure, lightweight server log interfaces, incident tracking database schemas, and status indicators.

Outcome & Engineering Impact

Shipped a minimalist status console that simplifies developer on-call handoffs and aggregates service health states.

Interactive Live Sandbox

System Architecture

DB STATE-DURATION COMPRESSION MODELSTATUS: AUDIT LOG PIPELINE ON-LINE
Health MonitorsPolls State (10s)Compactor APICheck State ShiftsFilters DuplicatesPostgreSQL LogWrites Transition OnlyOn-Call UIAlert Console

Console Architecture & Data Flow

Designed as an internal ops companion console, the system polls service states and logs reports to a central PostgreSQL database. Access is strictly secured to protect infrastructure telemetry data.

[Microservices] ──(Health Check Cron)──► [Database] ◄── [Ops Console (Secure Session)]
  • Health Scrapers: Chronologically scrapes HTTP status checks from configured microservices and updates server health indexes.
  • Data Aggregation: Aggregates history logs into simple incident bins, reducing queries and preventing DB timeouts during on-call incidents.

Implementation Detail

Technical Details & Implementation

  • Service States: Designed a simple status grid representing services with custom CSS pulsing alerts, reflecting status (Online, Degraded, Offline, Maintenance).
  • Incident History Table: Created a searchable logs table featuring pagination, status-based tagging, and detailed error summaries.
  • Security Lock: Implemented cookie-based authentication, blocking unauthorized outside agents from scanning internal IP addresses or telemetry endpoints.

Technical Validation & Metrics

Performance & Security Metrics

  • Telemetry Retrieval: Optimized PostgreSQL indices, bringing metric querying times down to 50ms on a table containing 10,000+ status records.
  • Scrape Reliability: Configured scrape workers with 3-second timeouts, ensuring scraping runs do not block resources or impact overall dashboard reactivity.

My Exact Contribution

Contribution Details

  • Full Implementation: Coded the dashboard, database schemas, scraper pipelines, and authentication system.

Challenges & Lessons Learned

Challenges & Key Decisions

  • Challenge: Scraper logs were filling database disks rapidly with duplicate 'healthy' entries.
  • Solution: Redesigned the table schema to use state-duration logic. Rather than logging checks on every interval, the system only writes to the DB when a service changes state, drastically reducing write operations.

Project Assets

Live demo is internal / restricted
Browse Source

Appreciate this build

5 appreciations