Alright, I need to see if I'm alone in this or if we've got a wider issue. For the past week, across three different client instances of Granola, I'm hitting persistent 'failed to load resource' console errors specifically in the Kanban view. The boards eventually load, but it's slow and clunky, and custom field values sometimes display as 'undefined' for a good 10-15 seconds.
My context, because environment matters:
* Two clients are on the Pro plan, one is on Business.
* All have a moderate number of custom fields (15-20) on the objects in question.
* We're using a mix of Chrome and Edge, latest versions.
* I've replicated it on different networks, so it's not a local ISP quirk.
This is giving me serious flashbacks to a Salesforce Lightning migration where premature caching logic crippled a custom console app. The symptoms feel similar—a view trying to load dependent data (like those custom field picklists or user avatars) before the core record set is fully fetched, causing the requests to fail and retry.
What I've tried, for anyone following along:
* Hard refreshes and cache clears (temporary fix at best).
* Disabling browser extensions one by one.
* Switching from list view to kanban and back. The list view works perfectly fine, which points to something in the kanban's rendering logic.
My big concern is user adoption. My teams are starting to complain, and "just refresh" isn't a sustainable solution. Has anyone else dug into this? More importantly:
* Are you seeing it on a specific plan tier?
* Does it correlate with a particular object type or a high number of pipeline stages?
* Has anyone opened a support ticket and gotten a meaningful response or workaround beyond the standard troubleshooting?
I'm about to escalate with our account manager, but concrete data from the community would be incredibly helpful. 🙏
Implementation is 80% process, 20% tool.
The Salesforce Lightning comparison is spot on. I've seen similar cascading failures in other SaaS platforms that use a decoupled frontend, where the Kanban component fires off independent GraphQL queries or REST calls for each card's custom field metadata before the main board query has resolved its authorization context.
Since you've ruled out networks and browsers, the next logical culprit is a recent deployment that changed the sequencing or batching of those background calls. Check if the failed resources in your DevTools console are consistently pointing to a specific endpoint pattern, like `/api/v1/fields/options` or a `/users/avatar` endpoint. That would confirm it's a backend ordering issue, not a general performance problem.
Have you noticed if the errors correlate with a particular custom field type, like lookups to other objects or multi-select picklists? Those often require separate, non-cached calls that can bottleneck.
SQL is not dead.
Agree on the lookups and multi-selects. They're often the worst offenders.
From a pure cost perspective, this type of un-batched, sequential call pattern is a performance killer that also drives up your cloud bill. Each of those failed calls still incurs compute time, and if they're hitting a database, that's I/O cost. The platform is paying for it on their end, which means you're paying for it in your subscription.
If the errors are for `/users/avatar`, that's just wasteful. Those should be aggressively cached CDN objects, not live queries failing auth.
cost per transaction is the only metric