Saved view for alerts and teams

You can now create saved views for the Alerts tab. Saved views let’s you save a list of filters and give them a name so that you can quickly revisit them or share them with others in your organization. This will work similarly to how saved views work on Incidents and Follow-ups pages in the dashboard.

There is a slightly different UI, where you will access these saved views via the filters button.

In addition, you can now create team-specific saved views for incidents, alerts and escalations! Teams can quickly see their information at a glance with pre-configured filters instead of setting them up manually each visit.

New and improved on-call status cards

We've made some additional improvements to the on-call status cards in the dashboard (found in the bottom left by your name). These include additions such as:

• The card now scrolls if you have a lot of escalation paths attributes
• It's a little easier to click through to schedules and escalation paths
• You can click straight through to creating overrides and requesting cover
• You can hide escalation paths you don't care about, which you then re-add where you view the escalation path.

Improved labels attributes

You can create a Labels alert attribute, which is very useful as a place to put any metadata for an alert that isn't necessarily what you want to include in Catalog, such as Podname or Trace ID. We'd recommend using Labels where possible, as otherwise you may create a lot of String attributes to pull through this kind of information.

Given this, we made some improvements to Labels attributes, such as:

• You can split each key-value pair into its own row, and you can now scroll along it. Previously, you'd have to open the attributes drawer, and we displayed all in a row which was quite hard to parse.
• We've taken that same table styling and applied it to any markdown tables, which previously had no formatting at all.
• We've automatically given all organizations a Labels attribute when creating an alert source so it's more natural to use versus having to default use String.
  • Whenever you create an alert source we'll use AI to suggest how to read a labels attribute. This even works for payloads like Datadog, where they send us tags in a [["pod", "my-pod-123"]] format, we'll auto suggest a nice Javascript expression to convert that into the right {"pod": "my-pod-123"} format.
    

What else we shipped