The brain of the MGT ecosystem. Cron registry, executor, heartbeat monitor.
Every scheduled task across MGT services routes through Mission Control on port 8001. It owns the cron registry (which jobs run when), the execution engine (runs them), heartbeat monitoring (are services alive), and alerting (fires when something goes wrong). Built with FastAPI, PostgreSQL, and Python. Three weeks from concept to production.
Port 8001
Address
Central control plane for MGT services
The Brain
Role
Orchestration for all scheduled tasks
In Dev
Status
Internal use, running ops jobs
Why It Was Built
As the MGT project count grew, scheduled jobs were spread across individual services with no central visibility. If a cron job failed, there was no alert. If a service went offline, nothing noticed until something downstream broke. The overhead of managing schedules across independent codebases was compounding with every new project.
Mission Control centralizes all of that. Jobs are registered once in a shared registry. The execution engine fires them on schedule. Heartbeats confirm services are alive between runs. Alerts fire when anything deviates from expected state. One dashboard shows the health of every scheduled process across the entire MGT ecosystem.
This is not a third-party tool. It is a custom control plane built for exactly the architecture MGT runs. Every design decision reflects what actually needed to be orchestrated across the real service graph.
What Was Built
PostgreSQL-backed registry of all scheduled jobs across MGT. Each entry defines the job name, target endpoint, schedule expression, expected runtime, and retry policy. Adding a new scheduled task is one write to the registry.
Python executor reads the registry and fires HTTP trigger calls to registered service endpoints at the correct intervals. Handles concurrency, timeout enforcement, and captures response status per run.
Services send periodic heartbeat pings to Mission Control. The monitor tracks last-seen timestamps per service. If a heartbeat goes stale beyond the expected interval, the service is flagged as offline and alerting begins.
Alerts fire when job execution fails beyond the retry limit, heartbeats go stale, or response times breach defined thresholds. Alert history is persisted so patterns can be reviewed, not just individual incidents.
All registry operations, job status queries, heartbeat ingestion, and alert management are exposed as async API endpoints. Services interact with Mission Control through a clean HTTP interface on port 8001.
Every job run is recorded: start time, end time, exit status, response payload, and retry count. The full history is queryable, so diagnosing a production issue means looking at real run data, not guessing.
Execution Flow
The executor evaluates the registry on each tick interval. Jobs whose next-run time has elapsed are selected for execution.
The executor fires an HTTP POST to the job's registered endpoint. The target service handles the actual work. Mission Control handles the orchestration.
Response status and payload are captured. If the job completes successfully, the next-run time is updated in the registry. The run is written to the execution log.
If the trigger fails or the response indicates an error, the executor retries according to the job's retry policy. Retry count and backoff are tracked per run.
If retries are exhausted or a threshold is crossed, an alert record is written and the notification path fires. The execution log entry reflects the final state.
Tech Stack
Custom control planes, orchestration systems, and internal tooling. Book a call and tell me what you are trying to coordinate.