Allow configurability of Slack Issue Alerts to remove some information

[mfn]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

The new sentry slack notifications consume a LOT more screen space:

from

to

Is there any way to get back a more brief version which conserves more screen estate?

They really consume a lot more height now and reduce the overall visibility of the channel they're posted too.

(I suspect it's related to #61455)

Expected Result

Actual Result

Product Area

Settings - Integrations

Link

No response

DSN

No response

Version

No response

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-settings-integrations for triage ⏲️

[Dhrumil-Sentry]

HI @mfn - We released these changes to early access customers. Thanks for this feedback.

This was a tradeoff we had to make to add more context to slack. (Here's a list of GH issues being addressed by these changes: #64116)

I'd love to understand what content from the following is unnecessary for you:

• Default tags?
• Event and user counts?

One option we're considering is making this configurable so you can avoid the blocks you don't need

[span]

I agree. Our slack channel for alerts have become very chaotic since these changes. I am currently trying to find a way to revert and it seems exiting early access will do it. I did not know we were in early access, and I did not expect early access to change formatting without warning or prompting.

For our use case, we only want the bare minimum. The previous alerts contained more than enough information for us. We simply check the incoming alert, assign it, and the assignee then opens the link to dig through the error. The extra, and formatted tags, does nothing for us. We only get alerts from prod. We are always running the latest version and usually have several releases every day.

The bare bones, text only formatting, was perfect for us, although even it contained more information then we needed. Now there are so many different "things" popping out, at least my eyes cannot focus on anything. I suppose allowing customers complete control over the message with a template would satisfy mostly everyone, but would perhaps be too much work.

Perhaps a middle ground where the more detailed message can be one alternative, while there is also an option for a "minimal version", that simply warns and then allows for assignment.

[Dhrumil-Sentry]

@span Thanks a lot for this feedback- This is the approach we'll likely take before we make this generally available.

[mfn]

making this configurable so you can avoid the blocks you don't need

Yes, please.

In my experience default slack notifications across the board of different apps usually get in the way because someone deems that's their best shot and millions of customers have to live with it then next where they try their best at communication between humans.

I'd love to understand what content from the following is unnecessary for you:

• environment: this is not necessary if you route them to dedicated slack channels for e.g. prod
• level: this was previously presented as a colored line on the left -> it was perfect and didn't need a place in its own line (colors were red, gray, …)

---

Effectively, the previous versions had the following elements:

• title: exception name (e.g. the class)
• message: exception message
• misc: project short issue id, link to per-project notification settings, date
• action bar: resolve, archive, assign

Additional as mentioned, the colored line on the left, indicating the error level.

It is… perfect? Personally here I could do with the action bar behind show more, but not sure if that's technically possible.

This concludes: everything else is not necessary, which means everything else the new notification brought, which effectively means the two new lines of summary

• environment, handled, level, release
• events, state, first seen

If we remove those two, we're more or less back with the old versions, sans the colored error level indicator line on the left.

Also, it seems the new version has a separate line at the bottom? Also not necessary imho.

Every pixel saved in height is a win. Every pixel.

---

As @span summed it up succinctly

we only want the bare minimum

[Dhrumil-Sentry]

Thanks for this feedback @mfn , I'll update the issue once we have these configurations in place

[jgillard]

What's the latest on this configurability? We're not in early access (as far as I know) but have just started seeing these notifications today, and I agree with the points above that say Slack channels with these in are harder to manage now that far fewer are visible at once. I also agree that "the bare minimum" is a good thing to aim for. A lot of the new information can be found by clicking the link through to the website so is not needed by us here.

[Dhrumil-Sentry]

Hi @jgillard thanks for your feedback - Hearing the feedback from EA customers - we already made changes to address some of these complaints to reduce screen estate and the changes were made generally available (#61601 (comment))

We don't have a timeline as to when we'll have the configurability, But I will comment here as soon as I have an update

[chestozo]

+1 for this request.
Monitoring a channel with Sentry reports where before we could see ~ 4 issues and now around 2.5 - is a bit frustrating (

[charettes]

+1 as well from us. We've been paying customers of Sentry for more than ~5 years with ~100 seats and this change has been disruptive enough that we've consider building our own Sentry -> Slack reporting tool to keep using the tool or migrate to something else that allows us to keep triaging issues effectively from Slack.

Please make this change configurable.

[elenasch]

One more +1 here. Would love to get the original UI back
The new format takes up way too much space, and it's making it harder to digest what errors we're seeing. I'll be honest I though there was some bug with the Slack integration when I first saw it. Was wondering who's on our side messing with it.

There is too much white space, and text is sprawled too much. I really only need the high level error message in shortest form possible (just like it was showed before) and can dig into all the details on Sentry UI if need be.

The red error circle emoji next to the error type is also out of place and disruptive. It's right next to the red Sentry logo

[nickooolas]

@Dhrumil-Sentry @ceorourke - thanks for making the uplifts on this integration, great to see the additional context rolling through on Users Affected counts / Events etc, makes it much easier!

That said, echo the sentiment of the others in that one of the critical issues with the new design of the messages, is the signficant increase in vertical padding/margin that the Block kit necessitates in its current implementation.

That said, I do believe, with the exception of the beloved coloured "quote" border just not being possible with Slack Block kit, there is definitely a way to get an alternative minimalist design that resembles the old format (which really minimised the extent of unecessary padding / margin etc, even with still keeping all the new context, but compressing it using only a single set of section block rather than one for each line of text.

Whilst the additional context is great, I think the elements used to compose it have quite varied padding/margins applied to each block element. Here is a way of achieving a much more consolidated version (by just using a single Section for the core issue/error message, and no code block etc)

{
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*<https://example.com|SlackClass::Sample>*\nFailed to load class SlackBotBuilder (SlackClass::Sample)\n*environment*\nproduction"
      }
    },
    {
      "type": "context",
      "elements": [
        {
          "type": "mrkdwn",
          "text": "SLACK-APP-E6W via Slack App Production | Apr 4th"
        }
      ]
    },
    {
      "type": "actions",
      "elements": [
        {
          "type": "button",
          "text": {
            "type": "plain_text",
            "text": "Resolve..",
            "emoji": true
          },
          "value": "resolve_error",
          "action_id": "resolve_error"
        },
        {
          "type": "button",
          "text": {
            "type": "plain_text",
            "text": "Archive",
            "emoji": true
          },
          "value": "archive_error",
          "action_id": "archive_error"
        },
        {
          "type": "button",
          "text": {
            "type": "plain_text",
            "text": "Select Asignee..",
            "emoji": true
          },
          "value": "assign_error",
          "action_id": "assign_error"
        }
      ]
    }
  ]
}

As you can see, this effectively resembles the previous design with the old UI kit.

I think the issue with the new implementation, is actually less about the additional information provided, and more about the fact that a new Section/Context Block is used for each line, rather than consolidating them within a single one (each time, more padding/margin added between them, where normally in rich_text or a singular one, normal text vertical spacing is used)

You can see how much of the spacing between elements contributes to its overall height:

Here's the block JSON from the current template for everyone elses reference re: the above point:

{
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": ":red_circle: ErrorClass",
        "verbatim": false
      }
    },
    {
      "type": "section",
      "block_id": "F6eRL",
      "text": {
        "type": "mrkdwn",
        "text": "```I am the error message here in a code block```",
        "verbatim": false
      }
    },
    {
      "type": "section",
      "block_id": "6R6fx",
      "text": {
        "type": "mrkdwn",
        "text": "environment: `production`  ",
        "verbatim": false
      }
    },
    {
      "type": "context",
      "block_id": "Zb+Dg",
      "elements": [
        {
          "type": "mrkdwn",
          "text": "Events: *123456*   Users Affected: *1234*   State: *Ongoing*   First Seen: *2024-04-04*",
          "verbatim": false
        }
      ]
    },
    {
      "type": "actions",
      "block_id": "qptWU",
      "elements": [
        {
          "type": "button",
          "action_id": "resolve_dialog",
          "text": {
            "type": "plain_text",
            "text": "Resolve",
            "emoji": true
          },
          "value": "resolve_dialog"
        },
        {
          "type": "button",
          "action_id": "archive_dialog",
          "text": {
            "type": "plain_text",
            "text": "Archive",
            "emoji": true
          },
          "value": "archive_dialog"
        },
        {
          "type": "external_select",
          "action_id": "assign",
          "placeholder": {
            "type": "plain_text",
            "text": "Select Assignee...",
            "emoji": true
          }
        }
      ]
    },
    {
      "type": "context",
      "block_id": "W7Gym",
      "elements": [
        {
          "type": "mrkdwn",
          "text": "Project: slack_sample    Alert: Slack App Production    Short ID: SLACK-APP-E37",
          "verbatim": false
        }
      ]
    },
    {
      "type": "divider",
      "block_id": "4hOLu"
    }
  ]
}

I feel like as an alternative to all the work involved in providing configurability to modify the Slack message elements by end users, a simpler approach would be to just replicate using Block UI what already was as an alternative template ie: switch between New (Expanded) and Legacy (Minimalist) formats in the Sentry UI. 🤔

[Dhrumil-Sentry]

@nickooolas Thanks a lot for this feedback ! We'll certainly discuss this approach and comment here once we have updates

[mfn]

This really needs to be slimmed down again from the default or be made configurable. The amount of screen space wasted is just too big.

Partly this is surely is slacks fault: even their most condensed layout never reached HipChats (anyone remember? 😼) "compactness", but the new Sentry integration dial this up.

Sure they look a bit less verbose since my initial encounter, but sorry to say: this is not enough.

Thx.

[chestozo]

Is this information dynamic? (I am guessing it is not)

And like that — it can be actually misleading and anyways devs should check Sentry for the up to the moment stats to see number of users affected / events tracked.