Spectrix - API Monitoring Tool

Lightweight API monitoring with real-time incident alerts (Slack, Discord, Webhooks).

🚀 Live Demo: https://spectrix.d3labs.tech/

Overview

Spectrix monitors your API endpoints and notifies you when something breaks - without heavyweight observability tooling.

It tracks:

• uptime
• response time
• failures
• incidents

and sends alerts via:

• Slack
• Discord
• Webhooks

Screenshots

Landing page and dashboard screens from the current UI.

Landing Page (Hero)

Landing Page (Full)

Service Page

Dashboard (Overview)

APIs

Incidents

Alert Channels

Logs

Features

• API endpoint monitoring (GET/POST/etc.)
• Timeout + retry support per endpoint
• Incident detection (based on repeated failures)
• Real-time alerts (Slack / Discord / generic webhook)
• Encrypted webhook URL storage (AES-256-CBC with per-version keys)
• Logs include status code, latency, and error type (DNS/timeout/network)
• Dashboard UI to manage services, endpoints, incidents, and alert channels
• Multi-service support (group endpoints under a service base URL)

Why I Built This

I built Spectrix because I needed a simple way to monitor my APIs without using heavy observability tools.

I wanted:

• scheduled endpoint checks
• failure detection
• instant alerts

This project also helped me explore worker-based systems, retry logic, and alert integrations like Slack and Discord.

Architecture

• Worker: polls endpoints that are due (nextCheckAt) on an interval
• Logs: stores every check result (success/failure, response time, error type)
• Incidents: created/resolved based on endpoint health over time
• Alerts: triggered on incident create/resolve and sent to configured channels

Tech Stack

• Backend: Node.js + Express (TypeScript)
• Database: MongoDB + Mongoose
• Frontend: Next.js (App Router)
• HTTP checks + alerts: Axios
• Validation: Zod

Setup

1) Clone repo

git clone https://github.com/your-username/spectrix.git
cd spectrix

2) Backend install

cd backend
npm install

3) Backend environment variables

Copy the example file and fill in the required values:

# macOS / Linux
cp .env.example .env

# Windows (PowerShell)
Copy-Item .env.example .env

Then edit backend/.env (Mongo URI, JWT secrets, CORS CLIENT, encryption key values, etc.).

4) Start backend

npm run dev

Backend runs on http://localhost:4000 and exposes the API at http://localhost:4000/api/v1.

5) Frontend install

cd ../frontend
npm install

6) Frontend environment variables

Copy the example file:

# macOS / Linux
cp .env.example .env.local

# Windows (PowerShell)
Copy-Item .env.example .env.local

Update NEXT_PUBLIC_API_BASE_URL if your backend runs on a different host/port.

7) Start frontend

npm run dev

Open http://localhost:3000.

Environment Variables

• Backend: see backend/.env.example
• Frontend: see frontend/.env.example

Alert Channels

You can connect:

• Slack webhook
• Discord webhook
• Custom webhook

Webhook URLs are encrypted before storing in MongoDB.

A test alert is sent during channel creation to verify configuration.

How It Works

1. Add a service (base URL)
2. Add one or more endpoints under that service
3. Worker checks endpoints periodically (based on each endpoint’s interval)
4. Failures are logged
5. After repeated failures → incident created
6. Alert sent to your configured channels
7. When the endpoint recovers → recovery alert sent

Deployment

• Backend: deploy backend/ to Render / Railway / Fly.io / VPS
• Frontend: deploy frontend/ to Vercel / Netlify

Notes:

• Set CLIENT to your deployed frontend URL so CORS allows requests.
• Enable monitoring in production with RUN_WORKERS=true.

Limitations

• Worker runs inside the API process (single instance)
• No alert rules/conditions yet (planned)
• No horizontal scaling for the worker (future)

Roadmap

• Alert rules (custom conditions)
• Email notifications
• Status levels (healthy / degraded / down)
• Charts and analytics
• Queue-based worker (Redis)

Contributing

PRs are welcome. Feel free to open issues for bugs or feature requests.