> For the complete documentation index, see [llms.txt](https://docs.lenses.io/latest/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lenses.io/latest/changelog/lenses-6.3/hq.md). # HQ Change log for Lenses HQ 6.3. {% updates format="full" %} {% update date="2026-10-09" tags="new,improvements,fixed" %} ## 6.3.0 {% hint style="warning" %} **Before you upgrade** * **Back up the HQ database.** HQ 6.3 changes the database schema in ways that cannot be undone, and HQ 6.2 does not start on an upgraded database. To go back to 6.2, restore the backup. If you run more than one HQ instance, stop every 6.2 instance before you start 6.3. * **Consumer groups in HQ need Lenses Agent 6.2.6 or later.** For environments with an older Agent, Studio shows a warning instead of their consumer groups, topic consumers and lag. Their consumer groups remain available in that environment's Legacy UI. {% endhint %} ### Role-based Data Policies (Public Preview) Data policies are now part of Lenses IAM roles. Platform teams attach masking rules to a role, and engineers, analysts and AI agents see only the data their role allows. On the same topic, developers can debug with personal fields masked while the team that owns the data sees everything. * **Defined once, applied everywhere.** Policies live in Lenses HQ and follow the topic across all your environments, instead of being configured Agent by Agent. * **The same view in every tool.** Studio, the Lenses VS Code extension and the Lenses MCP Server all return the same masked data, so an AI agent never sees more than the user it acts for. * **Policies as code.** Write masking rules in the role's YAML, with autocomplete, or start from the new **Default PII Masking** template.

The following data policy will apply to the email fields on the given topic name

{% hint style="info" %} Role-based Data Policies are in Public Preview and **off by default**. Each environment opts in from its Agent (6.3 or later) by setting `lenses.data.policies.legacy.enabled` to `false`. Contact Lenses Support to get help migrating your previous data policies before you switch: once enabled, the Agent will no longer applies the legacy data policies. {% endhint %} ### Consumer Group Monitoring: Lag Time and Catch-up Time Consumer lag is now measured in time, not just in messages. For every consumer group, Lenses shows how far behind it is and, at the current rate, how long it will take to catch up. 400,000 messages of lag can mean a few seconds or twenty minutes; now you know which, and can scale or step in before the business notices. * **Every consumer group in one place.** Studio lists the consumer groups of all your environments, with their state, members, topics, lag and catch-up time. Open a group to reset offsets, preview the record at an offset, or create an alert rule. * **Alert on delay, not on message counts.** Lag in seconds is exposed as Prometheus metrics, so your dashboards and alerting can page on "orders are more than 5 minutes behind", the way the business thinks about it. * **One scrape for all environments.** Prometheus collects consumer lag for every environment from Lenses HQ, labeled by `environment`, instead of scraping each Agent.
### **Malformed messages (poison pills) support** In Studio, bad records now show their real key and value sizes, and a record that cannot be decoded shows its raw bytes, as Base64 or plain text, so you can still inspect it instead of hitting a dead end. ### **New Consumer lag metrics global endpoint** Lenses now exposes consumer group lag metrics for all your environments from Lenses HQ, instead of scraping each Agent. \ Check the [Consumer Group Metrics Endpoint](/latest/deployment/configuration/hq/kafka-metrics.md) for more details. ### Improvements * **Redesigned Studio tabs.** Each tab is tinted with its environment's tier color, shows the entity name above the kind of view (for example **orders** above **Topic profile**), and has a descriptive tooltip. Tabs you had open before the upgrade are kept. * **Detail panels open over the table.** Selecting a row in topic messages, SQL results, audit and activity logs, alert timelines and K2K consumer groups opens its details in a panel that slides over the full-width table. Press **Escape** or click outside the panel to close it. All tables now use compact rows, and the row density setting has been removed. * **Faster topic Consumers tab.** The tab loads with a single request, so it appears faster on topics with many consumer groups. Environment and consumer group names open their Studio tabs, resized columns keep their width, and clicking an offset previews the record in place. With an Agent older than 6.3, the preview uses SQL. * **Schema details on the topic Schema tab.** For topics that use a schema registry, the tab shows the subject, its description and tags. You can edit the description and tags there, and open the subject in its own tab. * **Faster Studio search.** Results appear as each category returns, instead of after all of them. * **Re-run a SQL query from the results toolbar.** * **No limit on saved SQL queries.** The cap of 20 saved queries has been removed. * **K2K without a K2K license.** When your license does not include K2K, Studio no longer calls K2K, explains why it is unavailable, and disables **Replicate topic**. * **App migrations in favorites.** App migrations can be added to favorites from their menu. * **Roles sorted by name.** Roles under IAM in the Explorer are listed alphabetically. * **License expiry warnings.** Administrators see a banner 30 days before the license expires, and every user sees an urgent banner during the last 14 days and after expiry. A dismissed urgent banner returns 7, 3 and 1 days before expiry, and daily once the license has expired. * **Share links.** The breadcrumb bar has a button that copies a link to the open tab, and the **Actions** menu of topics, schema subjects, environments, consumer groups, connectors, SQL processors, K2K apps, IAM entities and more has **Share link**. Whoever opens the link lands on the same view. * **IAM details in the information panel.** Users, groups, roles and service accounts now show their details in the Studio information panel. * **Security updates.** HQ is built with Go 1.27.1, and axios, DOMPurify, js-yaml and other frontend dependencies were updated to address known vulnerabilities. ### Fixed * **Schema Registry in the Explorer for users who cannot list connections.** Users allowed to view schemas but not to list connections saw **Schema registry** grayed out. The Explorer no longer depends on that permission. Explorer nodes that fail to load now show a warning or error with the reason, and you can click the node to retry. * **Entities with special characters in their names.** Consumer groups, schema subjects, SQL processors, connectors, external apps and IAM principals whose names contain a space, `%`, `#` or `+` could open a tab for the wrong name that showed no data. They now open correctly from the Explorer, search, listings, menus, favorites and shared links, and existing favorites keep working. * **Connector Configuration tab.** After you switched connectors, the tab could still show the previous connector's configuration, and deploying it applied that configuration to the wrong connector. * **Alert rule channels.** Choosing channels for a consumer or producer alert rule in the rules list no longer fails with "Failed to update alert channels". * **Editing alert channels.** **Edit** on a channel whose settings include numbers or on/off values no longer crashes the tab, and on/off settings keep their value instead of reverting to off. * **Topic links in alerts.** The topic name in an alert's details now opens the topic's **Data** tab. Topics in the consumer and producer rules lists load their messages instead of failing with "Failed to create WebSocket connection" when an environment's display name differs from its name. * **Session checks on the sign-in page.** The sign-in page no longer checks for a session every 5 seconds while it waits for you to sign in. * **`lenses-hq` errors go to standard error.** Fatal errors are printed to standard error, so redirecting the output of `lenses-hq test-config --show` captures only the configuration. {% endupdate %} {% endupdates %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lenses.io/latest/changelog/lenses-6.3/hq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.