Dashboard
An optional web UI that ships in the repository under dashboard/. It is not
hosted anywhere and there is nothing to sign into — you run it on your own machine,
pointed at your own server, for as long as you want to look at it. It is a window on a
running server rather than a place to build things: watch delivery, read logs, inspect queue
health, and perform the few operational actions that are easier to click than to curl.
Templates and workflows are still authored in code.
The dashboard is not published to npm, not deployed for you, and not required to run NotifKit. Everything it shows is available from the REST API and the MCP server — it exists for the times a graph answers the question faster than a query does.
Running it
It is a Next.js app in the repository, run the same way you run any local dev server. Clone NotifKit, point it at your API, and start it — then close it again when you are done.
cd dashboard
npm install
npm run devTwo environment variables configure it, both with development defaults:
| Variable | Default | What it is |
|---|---|---|
NEXT_PUBLIC_API_URL |
http://localhost:3000 |
Base URL of the NotifKit API the dashboard reads from. |
NEXT_PUBLIC_ADMIN_KEY |
test_admin_key |
Your ADMIN_API_KEY. Used to list projects, then to fetch each project's own key. |
Both variables are NEXT_PUBLIC_, which in Next.js means they are inlined into
the JavaScript served to the browser — admin key included. On your own machine that
is fine, and it is why the dashboard is meant to be run locally rather than deployed. If
you ever do host it, put it behind your own authentication on a private network first;
published to a public URL as it stands, it hands your admin key to anyone who loads the
page.
What each page shows
| Page | Shows |
|---|---|
| Overview | A live feed of delivery events over server-sent events, straight from /v1/events/stream. |
| Logs | Per-attempt delivery history — channel, provider, status, timing — with a single notification's full trail on selection. |
| System Health | /v1/system/health and /v1/system/metrics: dependencies, worker heartbeats, and the Prometheus counters. |
| Analytics & Queue | Throughput and stream depth, for spotting a backlog before it becomes a page. |
| Dead Letters | The DLQ, with replay and discard. |
| Scheduled | Everything queued for a future sendAt, with cancel. |
| Workflows | Registered workflows and their runs, including which step a run is parked on. Triggering a run is available here. |
| Templates | What is currently synced, and what each template renders per channel. |
| Users | A user's contacts, channel and topic preferences, and quiet hours. |
| Projects & Keys | Projects, their API keys, and per-project rate limits. |
What it deliberately does not do
There is no template editor and no workflow builder. You cannot draw a sequence, and there is nothing to publish. Templates are synced from code on deploy and workflows are files in your repository, so that both stay in version control where they can be reviewed, diffed and reverted with the rest of your application.
The write actions the dashboard does expose are operational rather than authorial — replaying a dead letter, cancelling a scheduled send, triggering a workflow run, rotating a project key. Those are decisions you make once, in the moment, in response to something that already happened; none of them is a piece of behaviour worth keeping in a diff.