Alerts feature breakdown Aug '19

Let’s take a deep dive into the Alerts feature in Redash and discuss improvements and ROI.

Alerts list:

An overview of alerts with sorting ability and trigger state.

Here are a few points to discuss with my suggestions:

  1. “+ New Alert” button should be on this page (same for dashboard and query btw).
  2. “Unknown” is unclear. Its actual meaning is “No state determined yet until there’s a value to compare”. Change label to “N/A”.
    Also, @arikfr Any reason not to run the alert against current cached result?
  3. Show link to doc explaining each state.
    We can also show a legend at the top right.
  4. “Last Updated At” column may be perceived as related to the state, not the alert settings. I actually don’t see a point in having “Last Updated At” but do see value in “State Updated at”.
  5. Added “User” column title to allow sorting by.
  6. “Created at” remove redundant time (but still sort by timestamp).
  7. Add some filtering options.
1 Like

All points look valid :+1:

I’m wondering if the word “State” in “State Updated At” makes sense to non-techies. WDYT?

Disregard that - I thought you are implying that this value will show the last time the query was updated. Together with the “State” column it makes sense.

1 Like

Alert Page:

Alert configuration page.

Here’s the redesign.

Here’s what’s new:

  1. Alert status indication, am I right?

  2. Requested in Link to Query from Alert.

  3. Important to show how often a query auto-refreshes. If it doesn’t, we notify:

  4. More concise and clear. Condition options:

    28

  5. Alternative to “rearm seconds” with options:

    47

  6. Help trigger.

  7. Link to Alert Destination page (with clear tooltip).

  8. All destinations appear toggled off by default.
    Click destination to config it:


    If destination has issues, show alert icon with tooltip:

    37

  9. Wait, where’d Alert name input field go? The title is editable like in query and dashboard.

This layout has also taken into consideration future features based on requests. More on that later.

1 Like

Alerts List

:+1: I have to admit that even today I find it confusing when I want to create a new alert.

:man_shrugging: I guess not. Although N/A can happen in future runs as well.

An alert might seem no longer relevant if it was created 2 years ago, but if it was updated 10 days ago it’s a whole different story. I wonder if updated at is more important than created at?

It has its own column so we can sort by it? Because otherwise I think it makes sense to merge it with the state column.

There is no archive for alerts.

I would consider adding in the filters filter by state (to see all triggered for example).

Alert Page

Maybe we just open the Schedule Dialog here?

Should we clarify that this is only when the alert is triggered? I’m not sure it’s clear this way.

While this UX looks good, I’m not sure how it scales when there are many alert destinations. On the hosted Redash we have an account with 45 alert destinations (35 webhooks, 10 emails). I won’t be surprised if some self hosted instances have even more.

While it’s consistent with the other pages, it doesn’t look clickable much :thinking: (we might have the same problem on dashboards/queries, but we are just used to it). Not sure this is a pattern we need to keep. Or atleast we need to have some visual cue that this is the case when in edit mode.

Last Updated At: An alert might seem no longer relevant if it was created 2 years ago, but if it was updated 10 days ago it’s a whole different story. I wonder if updated at is more important than created at?

My feeling is that relevancy is better determined by “last triggered” (if it never triggers then it has no value) and in the near future by “enabled” state. Created and Updated I think are not indicative.

State Updated at: It has its own column so we can sort by it? Because otherwise I think it makes sense to merge it with the state column.

Yes for sorting. Don’t have data to determine if it’s valuable or not. Can leave as is for now.

I would consider adding in the filters filter by state (to see all triggered for example).

:+1:

Maybe we just open the Schedule Dialog here?

Right right :+1:

we have an account with 45 alert destinations (35 webhooks, 10 emails)

  1. Whoa. Doesn’t scale. Rethinking it.
  2. 10 emails would actually be represented in one entry.

Not sure this is a pattern we need to keep. Or atleast we need to have some visual cue that this is the case when in edit mode.

My thoughts exactly (I was very careful to keep the look/feel and conventions of the current design). I’ll try to make it clearer that it’s editable.

One more thing I realized: it makes sense to have an alert page that isn’t editable and an edit view (which is what you have here). Wdyt?

One more thing I realized: it makes sense to have an alert page that isn’t editable and an edit view (which is what you have here). Wdyt?

Makes so much sense :+1:
Having everything disabled is no way to treat a visitor.

@arikfr the Alert page design is based on our current content and implementation, but there are 2 feature options that can change this design dramatically, as they turn into more of an incident analysis page.

  1. Show alert history - in vertical log format or timeline graph.

  2. Show visualization with clear threshold marking.

Wdyt of these?

I don’t think it should turn into incident analysis page. This feature will probably be renamed to better describe its intention, maybe something like “Triggers” or “Workflows”.

We might still decide to show history but it will be a more elaborate one than just showing time and status. But regardless it’s out of scope.

1 Like