Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature suggestion: ignore certain errors #117

Open
craigfurman opened this issue Dec 12, 2024 · 5 comments · May be fixed by #130
Open

Feature suggestion: ignore certain errors #117

craigfurman opened this issue Dec 12, 2024 · 5 comments · May be fixed by #130

Comments

@craigfurman
Copy link

👋 My team recently started using this project, and we're definitely enjoying it so far. One UX issue we do have though, is that our workflow can't quite be expressed using the current status values (resolved and unresolved). I think that another possible state, "ignored", with the ability to filter the errors page to omit these, would solve this for us. A bit more detail on our workflow below 👇

We integrate with the telemetry to notify ourselves when a new or regressed (resolved -> unresolved) error occurs. We don't notify on subsequent instances of known errors. Zooming out, we use error-tracker to quickly alert us to new kinds of error, for triage, in conjunction with metrics-based alerting on a moving-average error ratio (e.g. "alert when >1% of HTTP responses on an endpoint have status 5XX in the last 30 minutes"). We believe balances MTTD with a workable signal:noise ratio.

As such, we tend to leave error-tracker entries related to transient, retryable errors (e.g. network flakes) open. This isn't because we don't care about them as such, but rather that a very low ratio of such errors, below some low percentage threshold, doesn't meet the urgency criteria to alert. Leaving the error-tracker entry open (unresolved) results in the notification behaviour we want (i.e. not notifying us).

I'd be interested in marking such entries as "ignored" in order to de-clutter the front page of error-tracker, which would make triaging of new entries easier.

Is this something you'd be interested in as a maintainer? I'd be happy to send a PR if so.

Cheers!
Craig
@craigfurman craigfurman mentioned this issue Dec 12, 2024
Closed
@craigfurman
Copy link
Author

I just spotted https://github.com/elixir-error-tracker/error-tracker/blob/main/guides/Getting%20Started.md#ignoring-errors, which is a nice alternative to UI ignores I think. Perhaps we don't need this issue anymore. I'll leave it open in case UI ignores are a thing you're interested in

@crbelaus
Copy link
Contributor

Hey @craigfurman, thanks for sharing your thoughts. I see how this could be a useful feature.

I need to think about this. I got a few ideas but need to put them in order first.

@crbelaus
Copy link
Contributor

I would like to separate the concept of "ignoring" an error and "silencing" it.

  • Ignoring an error means that it won't be tracked. Occurrences won't be recorded and won't show in the ErrorTracker interface. No notifications will be sent either.
  • Silencing an error means that it is tracked. Its occurrences are recorded and show in the ErrorTracker interface. But no notifications will be sent.

As you mentioned, we already have the capability of ignoring errors. Silencing errors is not possible yet. But it is something we would like to do.

The way I see it the silenced state is orthogonal to the resolved/unresolved states.

  • The status field would still be either resolved or unresolved
  • There would be a separate silenced boolean field that by default would be false

Silenced errors would still be recorded, but would not trigger telemetry events and thus won't trigger telemetry integrations either. Silencing and de-silencing an error would be done directly from the UI.

@crbelaus crbelaus linked a pull request Feb 14, 2025 that will close this issue
Open
@crbelaus
Copy link
Contributor

Pull request #130 implements this functionality. I've chosen mute and unmute as they are commonly understood and used in the wild.

@craigfurman
Copy link
Author

Looks great! Thanks for thinking about and implementing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Mute error occurrences elixir-error-tracker/error-tracker
2 participants
@crbelaus @craigfurman