Default sort on 'status' for crons is flipped, incorrectly reflected on frontend
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 22h 21m
- Merged PRs (30d)
- 586
Description

Currently the backend supports sorting cron monitors by a field such as `status`, `muted`, `name` along with a sort order being `ascending` or `descending`. The default on the backend right now is sorting by `status` `ascending` but as the above screenshot shows, the frontend believes the default is `status` `descending`.
One quick resolution is obviously just to align the frontend to the default backend behavior, but we should also examine what `descending` or `ascending` means in the context of `status`
According to our `muted` sort, you might map the value of `muted` to be 1, and `unmuted` to be 0
For `status` we should be doing something similar where `disabled`/`ok` have low values 0 and 1 respectively, and the more critical statues like `missed`, `timeout`, `error` would be higher. Currently this is exactly flipped from the [current implementation](https://github.com/getsentry/sentry/blob/9520a672f1aea72dc0754091ab1119a54e4b9c72/src/sentry/monitors/endpoints/organization_monitor_index.py#L67) as we wanted to keep the sort consistent with previous behavior where we sorted critical statuses to the top, so the backend defaults to `ascending` sort. This is fine, but is mismatched with how the `muted` sort order is defined.
Instead, lets flip the order on the backend, and then make the default sort on the fronted to sort on `status` `descending`
Contributor guide
Assessment
This issue has not been assessed yet.