A design refresh for every Dynatrace App, including yours

If Dynatrace looks different today, that's intentional. The design refresh incorporates customer feedback to improve the user experience by reducing visual layering on page surfaces and improving contrast in dark mode. Status and chart colors are more vibrant and easier to tell apart, and charts have new themed palettes alongside the existing options. The refresh reached every app at once, including the apps you built yourself, with no action required from you or from app teams.

Figure 1: Introducing the refreshed interface and color palettes.

Strato shipped the refresh to every app at once

Every app received the refresh on the same day because Dynatrace Apps share the Strato design system. Strato provides versioned design tokens for colors, shadows, and borders, along with shared components such as buttons, tables, filter fields, and time selectors. The visual refresh shipped as a set of token releases, so every app rendering those tokens picked it up at once without requiring each team to schedule reskinning work of its own. The same model extends to accessibility: keyboard support, focus indicators, and minimum target sizes live in the components and improve everywhere at once. The current state is documented in an independent conformance report.

Filter by a value instead of a field name

Customers asked to be able to filter without looking up a field name first. Now, you can. Type a value, and the filter field suggests the full expression: error surfaces status = error as the top match. You go from the thing in front of you to the filter that expresses it, which makes knowing the data model up front useful rather than a prerequisite.

Figure 2: Side-by-side design comparison in Notebooks, in light mode: Before - After.

Carry a time range from one app to the next

Customers frequently asked for an easier way to reuse a time range across apps. For example, someone might focus an investigation on a 40-minute window around a deployment, and then want the logs for that exact window. The time selector now keeps your recently used timeframes and offers them wherever you are. You can also copy a timeframe and paste it into another app or a different browser tab. Both changes operate on the same principle: the interface recognizes what you already did rather than asking you to recall it.

Figure 3: Side-by-side design comparison in Notebooks, in dark mode: Before - After.

Build your own apps on the same foundation

Because Strato is published as a design system including a component library, rather than a style guide, building your own Dynatrace app means assembling it from the same tables, filter fields, charts, and time selectors that the platform itself uses, so what you write looks and behaves like part of Dynatrace without any design work of your own. The design system is only the surface of what an app inherits, and the rest is what makes building here worthwhile:

• Your environment already modeled. The app queries Grail and Smartscape in place, so it inherits the topology, dependencies, and entity relationships Dynatrace already maintains rather than asking you to rebuild a data model before you can ask your first question.
• One query language across every data type. DQL reaches logs, metrics, traces, events, and topology in a single query, and Dynatrace Intelligence is available from your app for root cause and forecasting, so the analysis you would otherwise build yourself is already sitting underneath it.
• Permissions you don't have to build. The app runs inside Dynatrace IAM and is scoped to each user's existing permissions, so it shows a person exactly what they could already see, and there's no second access model to maintain, review, or audit.
• Data that stays where it is. Everything executes on the platform next to the data, so there's no pipeline to stand up, no export to schedule, and no second copy of your production data to govern somewhere else.

Adding the App Development MCP server speeds up development by giving your IDE assistant access to the component catalog with working code examples, the app experience standards, and a searchable DQL knowledge base available to it. This means you can describe the app you want in plain language and let the assistant work from current platform documentation instead of guessing at it. Getting something useful running doesn't require engineer-level knowledge of the platform, since the parts that normally demand it are the parts already in place.

What we're listening for next

This release came out of three specific asks: carry a time range across apps, filter without needing a field name first, and give the interface a lighter feel. Tell us what specific changes you'd like us to make next.