| ● |
sync:orders |
bbmini |
every 15 min |
14:38 |
18s |
on time |
1,284 rows |
healthy |
every revenue figure on the app |
| ● |
sync:fees |
bbmini |
hourly |
14:20 |
2m 40s |
on time |
3,904 rows |
healthy |
profit, ACoS, the Brief |
| ● |
rules:evaluate |
bbmini |
every 30 min |
14:30 |
48s |
on time |
6 fired · 33 staged |
healthy |
all bid and budget automation |
| ● |
temu:shipping |
bbmini |
daily 03:10 |
today 03:12 |
1m 06s |
on time |
842 rows, all zeros |
watch |
Temu economics — see Data Freshness |
| ● |
js:keywords |
bbmini |
daily 05:00 |
today 05:04 |
3m 20s |
on time |
2,140 rows |
healthy |
keyword research and rank tracking |
| ● |
sqp:weekly |
bbmini |
weekly Sun |
Sun 06:00 |
14m |
on time |
18,204 rows |
healthy |
the SQP board and share-of-voice |
| ● |
cogs:recompute |
bbmini |
nightly 02:00 |
today 02:00 |
6m 12s |
on time |
166 products |
healthy |
landed cost on every screen |
| ● |
checkpoint:wal |
bbmini |
at 3 boundaries |
today 06:00 |
38s |
on time |
drained 4.1 GB |
healthy |
the database staying recoverable |
|
A restart does not drain a large write-ahead log. It can destroy it. Three silent events lost about 22.6 GB of writes between them, and each one looked like a normal restart of a slow app. So the log is checkpointed at three boundaries instead, this row shows how much it drained, and the figure at the top is a warning colour above 1 GB — raising the size limit is the one fix that is never correct here.
|
| ● |
receive:docs |
bbmini |
every 10 min |
14:40 |
4s |
on time |
0 documents |
healthy |
invoice and packing-list intake |
| ● |
push:sellerboard |
bbmini |
weekly Mon |
Mon 07:00 |
2m 50s |
on time |
166 costs pushed |
healthy |
Sellerboard COGS parity |
| ● |
sync:walmart |
bbmini |
every 30 min |
14:32 |
22s |
on time |
41 rows |
healthy |
Walmart orders and fees |
| ● |
keepa:prices |
bbmini |
daily 05:30 |
today 05:31 |
1m 02s |
on time |
88 of 150 ASINs |
slow |
competitor prices — token budget |
| ● |
backfill:ca |
bbmini |
manual |
Aug 09 |
— |
never finished |
stopped at 2025-11 |
watch |
the CA history hole nothing else will close |
| ● |
amc:audiences |
bbmini |
weekly Tue |
Aug 05 |
— |
13d late |
no output at all |
silent |
AMC audience refresh — nobody noticed for 13 days |
|
A job that never started looks exactly like a quiet night. This one was launched with the system python instead of the virtual environment’s, so it died at the first import, wrote nothing, and reported nothing — and a scheduler that only records failures records nothing when a process never gets far enough to fail. That is why the Result column is never blank: “0 documents” is a result and an empty cell is an alarm.
|
| ● |
ci:github |
GitHub |
on push |
Aug 07 |
— |
— |
red, and meaningless |
disabled |
nothing — no ETL has ever run there |
|
The red badge on GitHub means nothing and is shown anyway. Every pipeline runs on this machine; the Actions workflows are vestigial and billing-blocked, so they fail on every push. Deleting the row would be tidier and would leave the next person to rediscover, from scratch, that the failing build they are staring at has never had anything to do with the app.
|
|
And the 401 that is not a 401. When the disk fills or the process is killed for memory, the app answers with an authentication error — so the first instinct is to go and re-issue credentials that were never the problem. Free the disk first, then restart: in that order, because a restart with a full disk and a large log is how writes get lost. This board leads with disk and log for exactly that reason.
|