Ah, latency as the canary in the coal mine. Smart. I've seen too many teams miss the slow degradation until the pipe bursts.
The consistency of the API latency data is, frankly, a mess. It's useful as a relative trend for a single workflow, but comparing latencies across workflows or trusting the absolute numbers is a trap. The timestamps often have weird clock skew, and the "duration" field might not account for queueing time within the platform itself.
You're already doing the right thing by spotting relative changes. To make it actionable, we had to baseline every workflow's normal duration and then set thresholds as a percentage of that baseline, not a fixed number. A workflow that normally runs for 2 minutes taking 4 is a five-alarm fire. A different workflow going from 45 to 50 minutes might be noise.
That daily aggregate table is the real pro move, by the way. It's the only way to keep the historical trends without grinding your dashboard to a halt. You've just moved the aggregation SPOF to a cron job, which is at least a failure mode you can sleep through.
Test the migration.