11 of 121 min

Dashboard

Dashboard: illustration 1Dashboard: illustration 2

Once a system starts working constantly, a set of scripts is no longer enough. You need a point where you can see its current state, the manual queue, errors and post-submit life.

So the project got a dashboard.

The first screen gathers the health layer: scheduler, browser session, quarantine, the result of the last run, daily metrics, Telegram runtime and the latest lines of the auto runner. Below are messages from employers, because the project doesn’t end at the moment of applying.

The second screen holds the working queue: pending approvals and questionnaires where I’m needed, and next to them the retry queue with cases automation couldn’t complete correctly on the first pass.

I don’t need the dashboard to “watch the bot”. I need it to keep the whole system under control: runtime, manual cases, errors, conversations and the points where automation is no longer enough.

Series contents
  1. Automating applications as an answer to market asymmetry
  2. How the bot compares me with a vacancy and assembles an application for it
  3. Why the closure of the job seeker API didn't kill the project but made it grow up
  4. How I kept the system's brain and replaced its transport
  5. The hardest part of auto-apply isn't submit
  6. Auto-apply in visible mode
  7. How the LLM in my project turns a vacancy into a cover letter
  8. Why full autonomy turned out weaker than managed autonomy
  9. I gave the system not only actions but also brakes
  10. How the project lives after applying: statuses, invitations, conversations and a manual dashboard
  11. Dashboard
  12. The most unexpected vacancy my bot found