feat: Add dashboard listing page

[pulpdrew]

Summary

This PR introduces a new dashboards listing page, which lists the available dashboards. Each individual dashboard is no longer listed in the sidebar. The new listing page supports searching by name and filtering by tag. This PR is a continuation of @elizabetdev's #1805, with some changes, additional tests, and refactorings.

This page does client-side sort and filter. There is no server-side pagination, filtering, or sorting. That is left as a future improvement, should it become necessary.

Screenshots or video

How to test locally or on Vercel

The listing page can be tested in vercel preview.

References

• Linear Issue: Closes HDX-3565
• Related PRs:

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hyperdx-oss	Ready	Preview, Comment	Mar 26, 2026 2:30am

[changeset-bot]

🦋 Changeset detected

Latest commit: c6b071a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@hyperdx/app	Patch
@hyperdx/api	Patch
@hyperdx/otel-collector	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Knip - Unused Code Analysis

⚪ No changes detected (182 issues on both main and PR)

What is this?

Knip finds unused files, dependencies, and exports in your codebase.
This comment compares the PR branch against main to detect regressions.

Run yarn knip locally to see full details.

[github-actions]

PR Review

• ⚠️ DashboardCard: <button> nested inside <a> — Card component={Link} renders an <a>, and Menu.Target > ActionIcon renders a <button> inside it. This is invalid HTML5 and can break keyboard navigation/screen readers. Consider using a CSS overlay (position: absolute) for the card link and keeping the ActionIcon outside the anchor, similar to how DashboardListRow separates the row click from the menu.

• ⚠️ URL ?tag= param not reflected in Select UI — If a user navigates to /dashboards/list?tag=sometag (e.g., via shared link) and that tag no longer exists, filteredDashboards silently returns empty but the Select shows no active filter (since the value isn't in allTags). The empty state says "No matching dashboards yet" with no visible indication of the active tag filter. Consider showing the tagFilter value even if it's not in allTags, or clearing a stale tag from the URL.

• ⚠️ Permanent transitional sidebar message — The "Saved dashboards have moved! Try the Dashboards page." text in AppNav.tsx is permanent code with no removal mechanism. If this is meant to be temporary, add a comment or ticket reference; if it's permanent, it'll read oddly once users are accustomed to the new location.

• ℹ️ DashboardListRow: imperative Router.push vs. Link — Table rows can't wrap anchor tags for full-row clickability, so the middle-click/cmd+click handling with window.open is a reasonable workaround. No fix required, just noting the intentional pattern divergence from DashboardCard.

[github-actions]

E2E Test Results

✅ All tests passed • 103 passed • 3 skipped • 1032s

Status	Count
✅ Passed	103
❌ Failed	0
⚠️ Flaky	1
⏭️ Skipped	3

Tests ran across 4 shards in parallel.

View full report →

[teeohhem]

Hmm this feels a little odd.

Part of me feels like people will use the "New Dashboard" button without making the decision up front whether it needs to be persisted or not. Maybe the "New Dashboard" button could spawn a dropdown with a few options:
New Dashboard ▾
├── Saved Dashboard Persisted to your team and visible to all members
└── Temporary Dashboard → Lives in your browser only, not saved to your team

Thoughts?

[elizabetdev]

@teeohhem @pulpdrew, should we consider having all dashboards saved as “draft” by default, and let users publish them when they’re ready?

This is a common pattern across many products that involve saved states and collaboration. It removes the need for users to decide upfront whether something is temporary or meant for the team.

In this approach, everything is automatically saved as a draft. When the user is ready, they can explicitly publish it to make it available to others.

That said, I understand this might be tricky to implement at this stage.

[pulpdrew]

@teeohhem Updated, with slightly different wording to avoid having to change the wording in EE where RBAC will mean dashboards are not always visible to all team members.

@elizabetdev I think that's a good idea! Do you picture a "draft" dashboard being persisted but not shared with the team prior to publishing, or not persisted at all prior to publishing? The latter would be pretty straightforward to implement, the former is more similar to Shared/Private notebooks. I think though that either way, we should handle that as a separate issue/PR, if we're OK with that.

[elizabetdev]

I picture it as:

a "draft" dashboard being persisted but not shared with the team prior to publishing

Yes, it seems similar to shared/private notebooks. Handling this in a separate PR seems fine.

[teeohhem]

Just a few small comments. The design and implementation is very clean.