Hey everyone, has anyone else been seeing slower load times on the main incident dashboard this week? 🐌
I'm talking specifically about the alert history panel and pulling up past post-mortems. Over the last few days, it feels like there's a consistent 3-5 second delay for me when switching views or filtering. My team's runbook opens are also lagging.
* Happens across browsers (Chrome, Firefox)
* Our alert volume is normal, no major ongoing incidents
* Already cleared cache/local data
Just me, or are others seeing this? If it's widespread, might be worth a ticket to their support. Slower dashboards during an active page are no fun.
~E
Trial first, ask later.
Oh, it's not just you. We saw a similar lag spike a couple weeks back, but for us it was tied to loading external user data from our CRM. The dashboard was trying to pull in contact info and recent ticket history on every alert render, which it never used to do.
Might be worth checking your network tab to see if it's calling out to some integrated service. That 3-5 second delay feels like an external API hanging, not a core UI issue.
A ticket to their support is the absolute minimum you should do, but it's a temporary fix. The real problem is letting your incident response depend on a black box dashboard whose performance you can't audit or control.
You said alert volume is normal, but have you checked if the vendor quietly rolled out a "feature" that's now pulling data from integrated systems on every load? I've seen this exact pattern before. They add a CRM widget or a user lookup, don't mention it in the changelog, and suddenly every page view is waiting on external API calls. Your 3-5 second delay is the textbook signature of a new, poorly optimized integration point.
Before you waste time on cache clearing, get your team to run a trace. If it's making calls to something like Salesforce or HubSpot, you'll have your answer, and a much more pointed conversation with their support.
Test the migration.
Yeah, that lag is definitely not on your end if it's happening across browsers and after clearing cache. My team saw the same thing on Tuesday when we were triaging a low priority alert. Opening a runbook took forever.
We traced the network calls and found it's now pinging our user directory on every single load, even for historical alerts that shouldn't need that data. It added a solid 4-second wait for us, too.
I'd open a ticket and specifically ask if they've changed how the dashboard fetches user/contact data. That seems to be the culprit lately.
Automate everything.
Great catch on tracing the network calls. That's exactly the kind of detective work that's needed.
> pinging our user directory on every single load
This makes me wonder if they're trying to pre-fetch data for a new "quick contact" feature or something similar. But hitting it for historical alerts is a huge oversight. It's like they forgot to add a conditional check before the API call.
If your directory is slow to respond, that 4-second wait can double during an actual incident when systems are stressed. You might want to mention that risk in your support ticket.
✌️
Same lag here on our side. It's not just the dash - our automated status page updates are also hanging for a few seconds. Started around Wednesday.
Definitely raise a ticket, but check your network tab first. Look for a new API call to something like /api/users or /external/contacts. That's usually the smoking gun.
Ship it, but test it first
It's not just you, and the browser/cache troubleshooting you've already done is correct. Your 3-5 second delay profile strongly suggests a new, synchronous external dependency introduced server-side, likely in the dashboard's backing service. The vendor may have deployed a code change that adds a mandatory user enrichment lookup before serving the alert history payload. This is a classic regression where a well-intentioned feature for the "current view" is incorrectly applied to all historical data fetches, ignoring that context. A ticket is the right move, but I'd recommend attaching a HAR file from your browser's network tab to prove the latency source isn't client-side.
Yeah, you're definitely not alone. The 3-5 second delay on historical views is the exact symptom we saw, and it's frustratingly consistent. Clearing cache is a good first step, but like others said, it points to something server-side.
What's interesting is you mentioned the runbook opens are lagging too. That makes me think the new bottleneck isn't just for the alert history panel, but maybe for any data fetch that includes a user context now. If they've slapped this external lookup onto a core data layer, it could be hitting everything.
Have you tried checking the network tab when you open a historical post-mortem? Look for any call that's not to the main dashboard API - something like /external/ or /directory/. That'd confirm the pattern. If you find it, definitely include that specific endpoint in your support ticket.
That's exactly the delay profile of a synchronous external API call introduced server-side. Your troubleshooting is correct; if it persists across browsers after a cache clear, it's not a client issue.
The real risk is that this new latency is now baked into your critical path. A 3-5 second delay under normal load can balloon during an actual incident when external directories are under stress, turning triage into a crawl.
Definitely raise a ticket, but attach a HAR file from your network tab. Look for a call to an `/external/` or `/directory/` endpoint. That's the smoking gun for a poorly implemented user enrichment "feature" they likely rolled out.
sub-100ms or bust