Developers
Collectors & Schedules
Every number in this app was written by a scheduled job in yuno-nms-cron. This page says which job, when it runs, what it writes, who reads it, and whether it ran.
Live status
The latest run of each tracked job, straight from the jobLogs table the jobs write to. If a card is amber or red, the numbers that job feeds are stale — check here before chasing a “wrong” uptime figure.
What the collectors are
This app never calls Ruijie, Huawei or Omada when you open a page. A separate service, yuno-nms-cron, does that on a schedule and writes what it learns into the shared database; the app only reads. So every figure on screen has an age: it is as fresh as the last run of the job that wrote it.
There are two families. The hourly poll keeps “right now” current all day. The overnight batch (weather, traffic, users, device logs) fills in yesterday between midnight and dawn. And there is one job that runs hourly but produces a daily number — the report card — which is the one people get confused by, so it has its own section below.
What runs when
One day, Philippine time. Each bar is a run; its length is how long the job takes. The red line is now.
Observed, not authoritative
lib/collectors.ts and these bars become exact.The two uptime jobs
current-uptime and uptime are the two names everyone mixes up. One is status now; the other is a score per day. Both run every hour.
What is changing
Where each number comes from
Read left to right: the cloud a job reads from, the job, the tables it writes, the screens that read those tables. To answer “why does the dashboard say 92 %”, find Dashboard uptime % on the right and follow the row back.
Every job
| Job | Route | Cadence | Takes | Tracked | Note |
|---|---|---|---|---|---|
| Hourly poll | /cron/current-uptime | hourly | ~17 min | jobLogs | Being renamed to `poll`; `/cron/poll` already answers. ~17 min from Heroku US, ~3 min once the cron runs in Seoul next to the database. |
| Daily report card (current) | /cron/uptime | hourly | ~3 h | jobLogs | One copy at a time since PR #34; a copy takes ~3 h, so the day's score lags. Being replaced by `daily-uptime` once the shadow diff is accepted. |
| Daily report card (shadow) | /cron/daily-uptime | hourly | ~1 min | jobLogs | Scheduler entry pending (hourly at :55). Rolls up yesterday and today each run. |
| Weather | /cron/weather | daily | ~2 min | logs only | 00:10 PHT is a requirement, not a slot: Google only serves the last 24 h, so a later run permanently caps the day. |
| Traffic | /cron/traffic | daily | ~3 h | logs only | |
| Users | /cron/users | daily | ~11 h | logs only | The longest job — runs into the working day. Not yet tracked in jobLogs. |
| Device logs | /cron/device-logs | daily | ~30 min | logs only | |
| Sites sync | /cron/groups | daily | — | logs only | |
| Devices sync | /cron/devices | daily | — | logs only | |
| Route health | /cron/route-health | daily | — | logs only | |
| Project behaviours | /cron/project-behaviors | weekly | — | logs only |
Tracked means the job writes one row per run to jobLogs with a heartbeat, so a killed or skipped run is visible and the live strip above can show it. The overnight batch is not tracked yet; its only trace is the server log and the row timestamps it leaves behind.
When something looks wrong
- Check the live strip first. A stale or failed job explains most “the number is wrong” reports. Note the job's name and the time.
- Find which job feeds the screen in the flow diagram. A wrong uptime % on the dashboard is the report card; a wrong online/offline badge is the hourly poll.
- Look at the run in
jobLogs: status, duration, error counts by type, the slowest calls, and where a still-running job is. The cron README has the queries. - Re-run one project before re-running everything:
/cron/projects/<id>/current-uptimeis tracked separately and never blocks the schedule.
Do not
Where the truth lives
- The cron repo README (
yuno-nms-cron/README.md) — the engineering description of every job, its tables, its budget and its environment variables. Start with the section “What each job is (plain English)”. - The Scheduler dashboard (Heroku today, Cloud Scheduler after the move) — the only authority on when a job fires.
lib/collectors.tsin this repo — the data behind this page: names, times, tables, readers. Edit it when a job changes, and the clock, the flow and the table follow.jobLogs— what actually happened, run by run, for the tracked jobs.