Update docs

Author: crbelaus

guides/Getting Started.md

@@ -56,7 +56,7 @@ Open the generated migration and call the `up` and `down` functions on `ErrorTra
 defmodule MyApp.Repo.Migrations.AddErrorTracker do
   use Ecto.Migration
 
-  def up, do: ErrorTracker.Migration.up(version: 4)
+  def up, do: ErrorTracker.Migration.up(version: 5)
 
   # We specify `version: 1` in `down`, to ensure we remove all migrations.
   def down, do: ErrorTracker.Migration.down(version: 1)
@@ -152,9 +152,27 @@ environments where you may want to prune old errors that have been resolved.
 The `ErrorTracker.Plugins.Pruner` module provides automatic pruning functionality with a configurable
 interval and error age.
 
-## Ignoring errors
+## Ignoring and Muting Errors
+
+ErrorTracker provides two different ways to silence errors:
+
+### Ignoring Errors
 
 ErrorTracker tracks every error by default. In certain cases some errors may be expected or just not interesting to track.
-ErrorTracker provides functionality that allows you to ignore errors based on their attributes and context.
+The `ErrorTracker.Ignorer` behaviour allows you to ignore errors based on their attributes and context.
+
+When an error is ignored, its occurrences are not tracked at all. This is useful for expected errors that you don't want to store in your database.
+
+### Muting Errors
+
+Sometimes you may want to keep tracking error occurrences but avoid receiving notifications about them. For these cases,
+ErrorTracker allows you to mute specific errors.
+
+When an error is muted:
+- New occurrences are still tracked and stored in the database
+- No telemetry events are emitted for new occurrences
+- You can still see the error and its occurrences in the web UI
+
+This is particularly useful for noisy errors that you want to keep tracking but don't want to receive notifications about.
 
-Take a look at the `ErrorTracker.Ignorer` behaviour for more information about how to implement your own ignorer.
+You can mute and unmute errors manually through the web UI or programmatically using the `ErrorTracker.mute/1` and `ErrorTracker.unmute/1` functions.

lib/error_tracker.ex

@@ -177,7 +177,15 @@ defmodule ErrorTracker do
   end
 
   @doc """
-  Mutes the error so next ocurrences won't send telemetry events.
+  Mutes the error so new occurrences won't send telemetry events.
+
+  When an error is muted:
+  - New occurrences are still tracked and stored in the database
+  - No telemetry events are emitted for new occurrences
+  - You can still see the error and its occurrences in the web UI
+
+  This is useful for noisy errors that you want to keep tracking but don't want to
+  receive notifications about.
   """
   @spec mute(Error.t()) :: {:ok, Error.t()} | {:error, Ecto.Changeset.t()}
   def mute(error = %Error{}) do
@@ -187,7 +195,10 @@ defmodule ErrorTracker do
   end
 
   @doc """
-  Unmutes the error so next ocurrences will send telemetry events.
+  Unmutes the error so new occurrences will send telemetry events again.
+
+  This reverses the effect of `mute/1`, allowing telemetry events to be emitted
+  for new occurrences of this error again.
   """
   @spec unmute(Error.t()) :: {:ok, Error.t()} | {:error, Ecto.Changeset.t()}
   def unmute(error = %Error{}) do

lib/error_tracker/ignorer.ex

@@ -2,6 +2,12 @@ defmodule ErrorTracker.Ignorer do
   @moduledoc """
   Behaviour for ignoring errors.
 
+  > #### Ignoring vs muting errors {: .info}
+  >
+  > Ignoring an error keeps it from being tracked by the ErrorTracker. While this may be useful in
+  > certain cases, in other cases you may prefer to track the error but don't send telemetry events.
+  > Take a look at the `ErrorTracker.mute/1` function to see how to mute errors.
+
   The ErrorTracker tracks every error that happens in your application. In certain cases you may
   want to ignore some errors and don't track them. To do so you can implement this behaviour.