Skip to main content
Version: v2.4.1

Dashboard Troubleshooting

Overview​

The Dashboard feature in AlphaSense enables users to create customizable monitoring dashboards with multiple widget types to track companies, documents, and market intelligence. Dashboards support various widget types including DocFeed (document streams), Document Lists, Portfolio/Price Monitors, and other data visualization widgets.

Users can create dashboards from scratch or use pre-configured templates from the Dashboard Gallery. Dashboards support advanced filtering capabilities, allowing users to link widgets to companies, watchlists, or industries, and apply dashboard-level filters through quick filters or the manage dialog. The "Explore from here" feature enables users to open widget queries in the main search interface for deeper investigation.

The dashboard functionality is primarily served by the dashboard-service and graphql-monitoring-dashboard services, which integrate with graphql-search for document queries, widget-service for widget rendering, and various backend services for data retrieval.

Common dependencies involved in dashboard operations include graphql-monitoring-dashboard, dashboard-service, widget-service, graphql-search, doc-search-realtime, ticker, user-service.

This document outlines common failure scenarios related to dashboard operations and provides troubleshooting steps for resolution.

Failure Scenarios​

Widgets Not Loading / Documents Partially Displayed​

Triage:​

Dashboard loads successfully, but individual widgets display "Failed to load" errors, infinite loading spinners, or render as blank containers. Some widgets load while others fail. DocFeed widgets may show "No documents found" despite documents existing. This typically indicates widget service failures or search service disruptions.

Common symptoms include:

  • Individual widgets showing "Failed to load" error
  • Continues document loading on specific widgets
  • "No documents found" in DocFeed widgets

Troubleshooting:​

Verify widget-dependent services are running:

kubectl get pods -n applications | grep -E "graphql-monitoring-dashboard|widget-service|graphql-search"

All pods should be in Running state with 1/1 ready containers.

Check pod health and recent events:

kubectl describe pod -n applications -l 'app in (graphql-monitoring-dashboard,widget-service,graphql-search)'

Look for:

  • Pod status like CrashLoopBackOff, OOMKilled, or ImagePullBackOff
  • Unexpected restarts or pod evictions
  • Resource pressure indicators
  • Recent deployment events

If pods are failing or stuck, restart the affected deployments:

kubectl rollout restart deploy graphql-search -n applications
kubectl rollout restart deploy graphql-monitoring-dashboard -n applications
kubectl rollout restart deploy widget-service -n applications

Check service logs for errors:

For graphql-monitoring-dashboard errors:

kubectl logs -n applications deployment/graphql-monitoring-dashboard --tail=1000 | grep -iE "error|failed|timeout"

For widget-service errors:

kubectl logs -n applications deployment/widget-service --tail=1000 | grep -iE "error|failed|timeout"

For graphql-search errors:

kubectl logs -n applications deployment/graphql-search --tail=1000 | grep -iE "error|failed|timeout"

Example error logs:

ERROR [widget-service] Failed to fetch widget data for widget ID 12345: Timeout after 30s
ERROR [graphql-monitoring-dashboard] Dashboard widget query failed: No response from graphql-search after 25s
ERROR [graphql-search] Document search failed for widget query: Connection refused to doc-search-realtime

Workaround:

Have users try:

  1. Refreshing individual widgets using the widget refresh button
  2. Refreshing the entire dashboard
  3. Removing and re-adding the failing widget
  4. Creating a new dashboard with the same widget configuration to isolate whether the issue is dashboard-specific or widget-type-specific

Dashboard Document Widgets Show Irrelevant Data​

Triage:​

Document widgets (DocFeed/Document List) display results that appear irrelevant or don't match configured search criteria, filters, date ranges, or document sources. This indicates query translation mismatch between widget configuration and search service execution, or differences between dashboard widget queries and main search behavior.

Troubleshooting:​

Compare widget results with main search:

  1. Click "Explore from here" in the widget context menu to open the same query in main search
  2. Compare results between dashboard widget and main search page
  3. If results differ significantly, escalate to #support-dashboard with details

Check dashboard-service logs for query translation:

kubectl logs -n applications deployment/dashboard-service --tail=200

Example error log:

WARN [dashboard-service] Widget query filter mismatch: Configured date range "Last 7 days" translated to incorrect timestamp range
ERROR [dashboard-service] Failed to apply document source filter for widget ID 789: Unknown source type "private-docs-v2"

Check graphql-search logs for widget-specific queries:

kubectl logs -n applications deployment/graphql-search --tail=200

Workaround:

If query translation issues are suspected:

  1. Refresh the browser and clear cache. This resolves transient query state issues in some cases, If issue persist.
  2. Recreate the widget with explicit filter configuration
  3. Use main search to construct the query, then save it as a widget

If the issue persists after configuration verification, escalate to #support-dashboard with:

  • Dashboard ID and widget ID showing irrelevant data
  • Screenshot of widget results vs main search results using "Explore from here"
  • Example documents shown in widget that appear irrelevant

Portfolio / Price Monitor Widget Doesn't Show Linked Company, Watchlist or Industry / Dashboard Filters Not Applied​

Triage:​

Portfolio/Price Monitor widget fails to display configured linked entities (companies, watchlists, industries). Widget shows "No Documents", empty results, or fails to load linked entity data. Additionally, dashboard-level filters applied via quick filters or manage dialog don't update widget contents.

Troubleshooting:​

Verify widget configuration:

Have the user:

  1. Open the widget context menu and confirm the widget is correctly linked to Portfolio/Price Monitor
  2. Check that the company, watchlist, or industry appears in the manage dialog or quick filters section
  3. Use "Explore from here" to open the widget query in main search and compare results
  4. Refresh the page and re-apply quick filters to force widget update

Check dashboard-service logs for filter update operations:

kubectl logs -n applications deployment/dashboard-service --tail=200

Example error logs:

ERROR [dashboard-service] Failed to apply dashboard filter to widget ID 456: Company ID resolution failed for ticker "INVALID"
WARN [dashboard-service] Portfolio widget shows no results: Linked watchlist ID 789 contains 0 companies
ERROR [dashboard-service] Price Monitor widget filter update failed: Industry ID 123 not found in system

Check graphql-monitoring-dashboard logs for widget query construction:

kubectl logs -n applications deployment/graphql-monitoring-dashboard --tail=200

Workaround:

Have users try:

  1. Refresh the browser page (hard refresh with Ctrl+Shift+R or Cmd+Shift+R)
  2. Remove and re-add the quick filters or manage dialog filters
  3. Edit the widget and re-link the entity (company/watchlist/industry)
  4. Create a new widget with the same configuration to test if the issue is widget-instance-specific
  5. Log out and log back in to clear any cached filter state

Dashboard Create/Update/Delete Operations Failing​

Triage:​

Users cannot create, edit, or delete dashboards. Operations return generic errors ("Something went wrong", "Failed to save changes") or fail silently with no user feedback. This indicates GraphQL mutation endpoint failures, database write permission issues, storage constraints, or validation errors.

Troubleshooting:​

Verify dashboard services are running:

kubectl get pods -n applications | grep -E "graphql-monitoring-dashboard|dashboard-service"

All pods should be in Running state with 1/1 ready containers.

If pods are failing, restart deployments:

kubectl rollout restart deploy graphql-monitoring-dashboard -n applications
kubectl rollout restart deploy dashboard-service -n applications

Check pod health:

kubectl describe pod -n applications -l 'app in (graphql-monitoring-dashboard,dashboard-service)'

Check dashboard service logs for mutation errors:

kubectl logs -n applications deployment/dashboard-service --tail=200

Example error logs:

ERROR [dashboard-service] Failed to create dashboard for user 12345: Dashboard name exceeds 100 character limit
ERROR [dashboard-service] Dashboard update failed: Database write permission denied for user
WARN [dashboard-service] Delete operation rejected: Dashboard ID 789 has linked dependencies
ERROR [dashboard-service] Transaction rollback: Failed to persist dashboard changes - database connection timeout

Check graphql-monitoring-dashboard logs for GraphQL mutation processing:

kubectl logs -n applications deployment/graphql-monitoring-dashboard --tail=200

If the issue persists, escalate to #support-dashboard with:

  • User and dashboard ID
  • Operation type (create, update, delete)
  • Dashboard configuration details (number of widgets, filter complexity)
  • Error message shown to user (exact text or screenshot)
  • Timestamp of failed operation attempts

Triage:​

Users navigate to dashboard gallery but encounter no templates, infinite loading, or "Failed to load templates" errors. This prevents dashboard creation from pre-configured templates, indicating service disruption or missing template data.

Troubleshooting:​

Verify dashboard service is running:

kubectl get pods -n applications -l app=dashboard-service

All dashboard-service pods should be in Running state.

Check pod health and recent events:

kubectl describe pod -n applications -l app=dashboard-service

Look for pod crashes, restarts, or resource issues.

Check dashboard service logs for template query errors:

kubectl logs -n applications deployment/dashboard-service --tail=1000 | grep template | grep -iE "query|gallery|load"

Example error logs:

ERROR [dashboard-service] Failed to load dashboard templates: Database query timeout after 30s
WARN [dashboard-service] Gallery query returned 0 templates - expected at least 10 default templates
ERROR [dashboard-service] Template image retrieval failed for template ID 123: S3 connection refused

Resolution:

Restart dashboard service to reinitialize connections:

kubectl rollout restart deployment/dashboard-service -n applications

Workaround:

If gallery templates are unavailable, users can:

  1. Create dashboards from scratch using the "Create New Dashboard" option
  2. Duplicate an existing dashboard and modify it
  3. Import shared dashboards from colleagues if available
  4. Wait for template service to recover and retry accessing the gallery

Dashboard Loads Slowly / Performance Issues​

Triage:​

Dashboard loads slowly (>15-20 seconds), with laggy interactions, slow scrolling, or delayed widget rendering. This indicates backend query performance degradation, resource constraints on services, or network latency.

Troubleshooting:​

Quick Resolution:

Have the user try:

  1. Reload the browser (hard refresh with Ctrl+Shift+R or Cmd+Shift+R)
  2. Log out and log back in to clear client-side state
  3. Try accessing the dashboard from an incognito/private browser window to rule out browser extensions

Service Health Check:

Verify dashboard-related services are running:

kubectl get pods -n applications | grep -E "graphql-monitoring-dashboard|dashboard-service|widget-service|graphql-search"

Check for pod restarts, crashes, or unhealthy status.

Resource Utilization Check:

Show pods exceeding 80% CPU:

kubectl top pods -n applications --containers -l 'app in (graphql-monitoring-dashboard,widget-service,dashboard-service,graphql-search)' | awk 'NR==1 || $3+0 > 80'

Get detailed CPU and memory resource configuration:

kubectl get pods -n applications \
  -l 'app in (graphql-monitoring-dashboard,widget-service,dashboard-service,graphql-search)' \
  -o json | jq -r '
  .items[] as $pod |
  $pod.spec.containers[] |
  "\($pod.metadata.name) [\(.name)]: CPU Request=\(.resources.requests.cpu // "none") Limit=\(.resources.limits.cpu // "none") Memory Request=\(.resources.requests.memory // "none") Limit=\(.resources.limits.memory // "none")"'

Check for OOMKilled pods:

kubectl get pods -n applications \
  -l 'app in (graphql-monitoring-dashboard,widget-service,dashboard-service,graphql-search)' \
  -o json | jq -r '.items[] | select(.status.containerStatuses[]?.lastState.terminated.reason == "OOMKilled") | .metadata.name + " - OOMKilled"'

If OOMKilled pods are found, memory limits may need adjustment.