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.
This site is in read only mode. Please continue to browse, but replying, likes,
and other actions are disabled for now.
ranbena
2
Here are a few points to discuss with my suggestions:
- “+ New Alert” button should be on this page (same for dashboard and query btw).
- “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? - Show link to doc explaining each state.
We can also show a legend at the top right. - “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”.
- Added “User” column title to allow sorting by.
- “Created at” remove redundant time (but still sort by timestamp).
- Add some filtering options.
1 Like
rauchy
3
All points look valid 
I’m wondering if the word “State” in “State Updated At” makes sense to non-techies. WDYT?
rauchy
4
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
ranbena
6
Here’s the redesign.
Here’s what’s new:
-
Alert status indication, am I right?
-
Requested in Link to Query from Alert.
-
Important to show how often a query auto-refreshes. If it doesn’t, we notify:
-
More concise and clear. Condition options:
-
Alternative to “rearm seconds” with options:
-
Help trigger.
-
Link to Alert Destination page (with clear tooltip).
-
All destinations appear toggled off by default.
Click destination to config it:
If destination has issues, show alert icon with tooltip:
-
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
arikfr
7
Alerts List
I have to admit that even today I find it confusing when I want to create a new alert.
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 
(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.
ranbena
8
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).
ranbena
9
Maybe we just open the Schedule Dialog here?
Right right
we have an account with 45 alert destinations (35 webhooks, 10 emails)
- Whoa. Doesn’t scale. Rethinking it.
- 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.
arikfr
10
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?
ranbena
11
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
Having everything disabled is no way to treat a visitor.
ranbena
12
@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.
-
Show alert history - in vertical log format or timeline graph.
-
Show visualization with clear threshold marking.
Wdyt of these?
arikfr
13
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
ranbena
15
Even-though some comparison conditions (==, !=) work for strings, they can’t be used cause the ui constrains the threshold value in a number only input.
One approach would be to substitute the input with type="text" and show an “invalid value type” error only when:
- current top row value doesn’t evaluate to a number.
- selected operation is not
=or!=.
ranbena
16
Here’s how it looks:
No error 
Number column value, number operator, number threshold value
String column value, string operator
Invalid value type error message 
String column value, number operator - mismatch
Number operator, string threshold value - mismatch
ranbena
17
@arikfr @levko U can play with it here https://deploy-preview-4081–redash-preview.netlify.com/alerts/11
ranbena
18
Having the “Delete” button in such proximity to the “Save” button makes no sense.
Especially knowing that “disable/enable” is an upcoming feature, better have a dedicated place for such dangersome actions.
Here’s a suggestion:
@arikfr wdyt?
1 Like
ranbena
19
UI design for the two alert modes - view and edit.
View mode
- Alert Status.
- Alert metadata.
- Read only apart for Destination config.
- Notification summary.
- Edit this Alert button.
Edit mode
- All config editable, including alert name.
- Status and metadata hidden.
- Danger zone options appear.
- Save and Done Editing buttons.
arikfr
20
About the error messages when there is a mismatch between threshold, value or operator: I would go for clearer error messages –
- “Value column type doesn’t match threshold type.”
- “Value column isn’t supported by condition type.”
The location makes sense. But not sure about placing “disable alert” under “Danger Zone”, as it’s not that dangerous 
Maybe we can drop the Danger Zone title?
- I would move the metadata to be on the right side and make it look more like the one we have for queries for consistency.
- Not sure about the Edit button location. Maybe it should be where the Help Trigger is currently located?
- I would remove the help trigger from the view mode.
1 Like