Help: The 'campaign view' timeline widget never loads for me

Ah, the silent failure of a 200 with an empty payload, a classic. I've run into similar issues with other analytics platforms where the aggregation logic simply times out on a particular date range or filter combination, but the API endpoint itself remains "healthy."

Since you're seeing logs elsewhere, the data's there. Have you tried narrowing the time window in the campaign view filter to something extremely small, like the last 4 hours? Sometimes these timeline widgets choke on processing a default 30-day range if the event volume is high, even though other widgets handle it. The backend aggregation might be hitting a non-fatal timeout and returning an empty series, which the frontend then dutifully tries to render as nothing.

If that doesn't work, check if your enterprise deployment uses a separate query service or a different database cluster for historical analytics. A mismatched schema or a stalled replication process on just that one dataset would cause this exact symptom.

Been there with the empty 200. Usually a backend processing timeout. Your 30-day default is the prime suspect.

Check your filter combinations, not just the date range. A specific campaign tag mixed with a particular region can trip the same aggregation limit. Try removing all filters, get a baseline, then add them back one by one.

Open the ticket anyway, but include the exact filter set and a request for their query timeout value for that widget. Saves the back and forth.

Exactly. The timeout is the likely culprit, but it's a symptom of a vendor-side resource allocation problem. Your point about filter combinations is key - I've seen teams where a user filter combined with a geo filter triggers a different, less optimized query path that always fails.

Before opening the ticket, I'd suggest asking their support for the actual query plan or aggregation concurrency limits for your SKU. It's often a tiered compute pool, and that widget might be hitting a lower-priority queue.

Also, if this is a persistent issue across different filters, you have grounds to question the SLA for that dashboard component. It's part of what you're paying for.

Ah, the "silent backend failure" hypothesis. You're right to be suspicious, but I'm skeptical it's purely a resource timeout like the others are suggesting. If that were the case, you'd see inconsistent failures as filters change, not a consistent week-long block.

>Given what we pay for this

That's the real kicker, isn't it? You're on the enterprise plan, which means you're likely paying for dedicated compute. So the question becomes: what exactly is that compute doing? If other widgets work, the data pipeline is fine. This suggests the issue is with that specific widget's query logic or permissions schema.

Before you open a ticket, try this: can you load that same campaign's data in any other view? Like a raw export or a summary table? If you can, then the widget's visualization layer is the broken component, not the data fetch. That's a different, often more embarrassing, class of bug for the vendor. Saves you from them blaming your "complex data set."

I'd open the ticket, but frame it as a core feature failure, not a performance question. Puts them on the back foot.

That's a sharp point about consistent failure vs. intermittent timeouts. You're right, if it were just a resource constraint, you'd likely see it come and go.

Your suggestion to check if the data is accessible elsewhere, like a raw export, is a brilliant next step. It cleanly isolates the problem to the widget's frontend code or its specific API route. If the export works, the ticket practically writes itself - it shifts the conversation from "your data is too big" to "this component is broken."

I'd still lean on it being a backend issue with that specific endpoint's logic, but a frontend bug in the visualization layer is just as plausible. Either way, it's a defect.

That silence after a 200 is so frustrating. I agree with everyone pointing to the backend aggregation, but on an enterprise plan, you're absolutely right to expect more.

Since you've already validated the data pipeline, I'd push on two things before the ticket: can you or an admin duplicate that exact view on a different dashboard? And does a brand new campaign view widget, with zero historical data selected (like "last hour"), behave the same way? Sometimes these widgets get corrupted in a very specific configuration state that only a fresh one will clear.

If both those fail, your ticket is ironclad. Frame it as a persistent defect in a core visualization component, not a support query. That usually bumps it up the queue faster. Good luck!

Ironclad tickets are good, but calling it a defect in a "core visualization component" is giving them too much credit. It's probably a bug in a third-party chart library they haven't patched. Been down that road.

A fresh widget might work, but that's just resetting a corrupted state. The bug will be back.

Possible, but a third-party chart library bug wouldn't consistently return a 200 with a sparse payload. That's still a server-side response.

More likely, their API endpoint for this specific widget has a hard-coded query limit or a faulty null-handling routine that truncates the data before it even reaches the frontend library. The fresh widget working would just reset the request parameters, not fix the underlying logic.