assistant: You’re right — with the first pass of the “derived failure” logic, those Notion runs still looked ok in the dashboard because the failure text was “soft” (missing API key / needs config) and didn’t match the initial failure patterns, and we had already advanced the byte offsets so we weren’t reprocessing them.

I just fixed both issues in the dashboard:

After rerun, these are now correctly marked as failures in data/activity.json:

Pushed to openclaw-dashboard main: b6afab3 (fix: classify config/auth cron runs as failures).

Refresh the dashboard and those runs should show up as failed now. If you want, I can also tweak the heuristic so “needs go-ahead” is shown as blocked instead of error. user: ok good. can we make the error ones more easier to see - either change the type or color code the failure rows [message_id: ed6f7890-ec52-433a-aa82-cbb6ad65b3e9] assistant: Yep. I updated the dashboard Activity UI so “failed” cron runs pop visually.

Changes shipped (openclaw-dashboard main commit 7ece60d):

So you’ll still see type = cron:run, but failures are immediately obvious.

Refresh the dashboard Activity tab and you should see the Notion runs from 4/6–4/8 highlighted red. If you’d rather have the type actually change (e.g. cron:run:failed so the type filter works), say so and I’ll tweak the ingestion to emit a different type for error runs. user: great, can we also exclude the sync activity job from the activity log. right now it's flooded with the cron job run and associated git commits [message_id: 8c1c13b7-5105-4295-b8c2-ac38c39c188a] assistant: Yep — did it.

I updated sync:activity so the Activity feed excludes:

Importantly, it also prunes historical entries matching those rules, so the feed immediately de-floods (your activity.json dropped from ~1150 → ~1063 entries after the rewrite).

Pushed to openclaw-dashboard main: dab98be (chore: exclude activity sync noise from activity feed).

If you also want to exclude the cron snapshot sync commits (chore: sync cron snapshot) or other “maintenance noise”, tell me which subjects/jobIds and I’ll add them to the same exclude lists. user: so it also won't do the git commits on those anymore right? [message_id: 27eff7fd-bfcf-48b9-93b9-5b569af035a6] assistant: No — it will still create and push those git commits as before.

What we changed is only what gets logged into data/activity.json:

So the repo will keep getting chore: sync activity commits on schedule; they just won’t appear in the dashboard Activity list anymore. user: System: [2026-04-09 01:00:19 UTC] Cron: Synced Dashboard Activity.

but it won't create a new commit every 15mins bc we are now exclude that activity? [message_id: 4518e29e-a802-4305-bc78-c12a31076981] assistant: It still might, yes.

Excluding the activity-sync job from the activity feed only stops us from writing those particular events into data/activity.json. But the cron job will still commit every 15 minutes whenever sync:activity produces any change to either:

And it can still change because:

In fact, your log at 01:00 shows it added 1 event, so it legitimately changed data and committed.

If your goal is “don’t create a commit unless there’s something meaningful,” we can tighten it further, e.g.:

Tell me which behavior you want and I’ll implement that in sync-activity.js / the cron schedule. user: right now it's creating a new commit every 15 mins bc it's logging the sync activity cron job run. but if we exclude that, and assuming nothing else happened, then it won't have a new activity and thus nothing to commit? [message_id: c9d1492f-5b6f-4645-bfde-84455ff8903d] assistant: In theory, yes — if the only “new event” every 15 minutes was “the sync job itself ran”, then excluding that should stop the churn.

But with the script as it exists right now, it can still create a commit even when nothing meaningful happened, because it updates state metadata timestamps on every run.

Specifically in scripts/sync-activity.js:

So even with added: 0, activity-state.json changes (new timestamp) → git status sees changes → cron commits.

If you want “no new events ⇒ no commit”, we should change sync-activity.js so that when added === 0 it:

I can patch that now so the 15-min job becomes “commit only when something new was actually ingested.” user: o kyes pls [message_id: 95d01217-62ad-4f54-adb8-41886230a999] assistant: Done. I patched openclaw-dashboard/scripts/sync-activity.js so when added === 0 it does not rewrite data/activity.json or data/activity-state.json.

That means: if nothing new happened (and we’re excluding the activity-sync job’s own run + commits), the 15‑minute cron should now exit cleanly with no git diff, so it won’t create a new commit every time.

I verified locally:

Pushed: commit 61ce0dd — fix: avoid rewriting activity state when no new events.

Next time the cron runs, if there are truly no new events, it should stop committing. user: also Cron jobs definition changed is all it shows for cron job changed type. is it possible to show what actually changed [message_id: 0802b7e2-5d8d-4836-b16f-a87800353009] assistant: Yes — we can, and I wired it up so future cron:jobs-changed events include what changed (not just “something changed”).

What I shipped (openclaw-dashboard main commit 6ed88d2):

Why you’re still seeing the old text right now:

If you want, I can also update the Activity UI to render a compact “diff summary” line for these events (e.g. +1 -0 ~2 with a hover/click to show changed job names).