Back to projects

Operations Dashboard

OpsSlate

Self-hosted routines are harder to trust when job health, dependencies, checks, and maintenance notes are spread across places that are slow to scan.

Abstract operations dashboard with job health cards, dependency map, and status timeline.

Role

Product engineering, operational UX, and lightweight systems design.

Engineering Focus

.NET Razor Pages, YAML job configuration, JSON status files, dependency-aware final status, and safe config editing.

Public Scope

Public overview of operations visibility without private infrastructure details.

Operations foundation

Project Foundation

Public-safe case study focused on self-hosted-first job-health visibility, dependency awareness, and private deployment boundaries.

Evidence Signals

  • The documented product surface reads job definitions from configuration and status from per-job JSON output.
  • Dependency checks can mark a job as blocked when prerequisites are not successful.
  • The local smoke runner uses generated safe fixture data for repeatable validation without production configuration.

Engineering Highlights

  • YAML job definitions and JSON status files keep the operating model simple and inspectable.
  • Final status precedence covers missing files, invalid status data, errors, staleness, warnings, success, and dependency blocking.
  • Add, edit, and delete workflows preserve job configuration carefully and keep script execution out of the current release.

Portfolio Proof Points

  • Status precedence
  • Dependency blocking
  • Self-hosted-first privacy boundary

OpsSlate is a lightweight self-hosted operations dashboard foundation focused on automation visibility, job health, dependency awareness, and practical status review.

Problem Shape

Self-hosted routines can become harder to trust when job health, status, dependencies, repeated checks, and maintenance notes live in separate places. The product direction is a small dashboard that makes operational intent easier to see without turning into heavy infrastructure or exposing private operations.

Product Direction

  • Keep the operating model lightweight.
  • Make job health, status, and dependency signals easier to scan.
  • Use simple configuration and status files where they fit the self-hosted-first model.
  • Preserve careful add, edit, and delete behavior for configuration changes.
  • Treat script execution, notification sending, and broader automation as future direction unless separately implemented and validated.
  • Describe operational patterns without publishing private service details.

Engineering Notes

The useful engineering work is in restraint: small configuration surfaces, obvious status language, dependency-aware checks, and workflows that reduce repeated manual checking. The documented foundation reads job definitions from YAML, reads each job’s status from JSON, and applies final status rules that keep missing data, invalid status data, stale output, warnings, errors, success, and dependency blocking distinguishable.

OpsSlate also shows a practical self-hosted-first privacy boundary. The app is useful because it makes private operations easier to scan, but the public case study does not need internal job names, private operational destinations, dashboards, host details, or live app links to explain the engineering work.

Evidence Signals

  • The documented app foundation uses ASP.NET Core Razor Pages.
  • Job definitions are configuration-driven, and status is read from per-job JSON output.
  • Final status precedence is explicit, including dependency blocking when prerequisites are not successful.
  • Add, edit, and delete workflows back up configuration and preserve existing job entries rather than rewriting unrelated state.
  • A local smoke runner creates safe temporary fixture data for repeatable validation without production configuration.

Public Boundary

This page focuses on product direction and operational clarity. Private app links, internal job names, private infrastructure details, private operational destinations, credentials, logs, private routes, and environment-specific URLs stay out of view.

Public case study only. Private operations, credentials, logs, dashboards, live app links, real screenshots, and infrastructure details stay out of view.