New package: Monitoring CLI / UI

[noxify]

Extracted feature request from #41

---

Providing a "bundled" version with an ORM of my choice ( or just plain sql via pg or postgres.js ) should work.
I just have to make sure it's configurable ( see #40 where I try to make schema and table name configurable ).

Have seen that "absurd" uses vite for the UI, which should work, but have to compare it with a bundled nextjs app.

For the CLI approach, maybe sst/opentui would be cool to have an interactive tui 🤔

---

We have to decide, if we want to provide two packages ( @vorsteh-queue/ui & @vorsteh-queue/cli ) or just one package which provides both ( e.g. @vorsteh-queue/monitoring )

Ideas for the package name(s):

• UI: @vorsteh-queue/studio /or@vorsteh-queue/ui
• CLI: @vorsteh-queue/cli

[noxify]

Maybe we could implement something like vitest.

Default is the CLI usage, but if you want to manage the jobs via a UI, you can simply add a --ui param which will start the webserver.

I'm currently unsure about the configuration.

[noxify]

Hey @maelp ,

i spent the last days to check how we could provide a monitoring ui and would ask if you would be so kind to take a look and provide some feedback if something is missing :)

The UI is inspired by the absurd ui and https://data-table.openstatus.dev/infinite . It's based on tailwind & shadcn components.

What it's already working:

• Simple dashboard with a summary
• queue detail view with job stats (
• configurable refresh interval

Next steps are:

• adding a data table to the queue detail view to list the existing jobs for the current queue
• adding a jobs detail view ( plan is to create this like you can see in the openstatus datatable )
• job actions ( like cancel, retry, etc. )

Bildschirmaufnahme.2025-11-07.um.14.37.41.mov

I started with a nextjs based approach but switched later to a vite based approach via tanstack/start.
why? The idea is to provide the bundled app as package so you can call it directly.

The app expects an config file which can be passed via an env variable ( QUEUE_CONFIG ).

The config file is really simple and includes only an array with the queue definitions.

// queue.config.ts
import {queue as notificationQueue} from "./definitions/notifications"
import {queue as emailQueue} from "./definitions/email"
export default [
  notificationQueue,
  emailQueue
]

With this approach we only have to extend the core class + adapter with some additional methods ( like getJobs or getJobDetails ) and you have also all methods available in case you want to create your own monitoring dashboard.

[maelp]

Looking great! Exactly what I had in mind! really cool

[noxify]

Queue Details sheet:

Trigger button:

[noxify]

added the initial data table:

Question is, which columns should we provide as default and which are needed at all for the data table?
In the detail view, I will provide all available fields.