AI PORT BackOffice

Internal system that watches every company service from one panel — payment flows, server health, AI usage, alerts and backups.

Ownership: Company · solo developer · AI PORT
Role: Solo developer — design, backend, monitoring, integrations, operations
Period: Mar 2025
Open link: Live ↗

https://backoffice.aiport.tr№ 004

Context

In a small company shipping several products, "everything that runs in the background" scatters quickly: payment-provider dashboards, server monitoring, AI-provider invoices, backups, customer notifications. BackOffice gathers all of it in one internal panel: payment flows, server status, AI usage and cost, the alerting system and backup jobs for every service, FLY AI and Export AI first among them.

I wrote the project end to end on my own: data model, integrations, scheduled jobs and the interface.

Constraints

A false-positive alert is the death of an alerting system; thresholds and severity levels must be tunable.
Access to payment and customer data must be role-based and auditable.
Adding a new service must be configuration, not a code change.

Architecture

Collectors and Prometheus → rule engine → channel; the panel receives live status over WebSocket/SSE.

The backend is Node.js + PostgreSQL (Prisma); server metrics come from Prometheus and live status streams to the panel over WebSocket/SSE. Alerts fan out to Telegram, WhatsApp and email by severity.

TODO: To be extracted from the source: how collectors work (polling / webhooks), the queue, where backups go.

§ Decision log

Decision	Alternative	Why
01One panel; every service follows the same health · money · usage · alerts template	A separate admin screen per product	Several products live in the company at once; a shared template makes it possible to onboard a new service to the panel in a day.
02Alerts arrive where people already look (Telegram / WhatsApp / email)	In-panel notifications only	When a payment webhook fails at 03:00 nobody opens the panel; the alert must reach a phone, and the channel must follow severity.
03Metrics live in Prometheus; the decision and alert layer lives in the panel	Collect every metric in my own tables	Time-series collection is a solved problem; Prometheus gathers, the panel owns only the "who is told, when" rules and the workflows. Live status streams to the screen over WebSocket/SSE.
04Backups and scheduled jobs are part of the panel itself	Separate cron scripts on the server	What matters is seeing that a backup did not happen; once jobs are visible in the panel, "last successful backup" reads at a glance.

§ Outcome

TODO
Services monitored: 3
Alert channels: Prometheus
Live metrics source: 1
Developers

§ Retrospective

What I would do differently today

TODO: What would you do differently today? (e.g. move alert rules into Alertmanager too and keep only workflows in the panel, put event history in a separate store…)