Alerts and the weekly digest

Muster tells you about problems two ways: an alert the moment a monitor fails, and a digest every Monday summarising the previous week.

Alert channels

Each monitor has two independent alert channels, Email alerts and Webhook alerts, on its create and edit form. For each channel you tick which failures it should carry, and give a destination:

• Missed and recovered: an alert when the monitor goes missed, and another when it recovers.
• Non-zero exits: an alert when a connected command reports a run that exited non-zero or failed.

Tick both, one or neither. A channel with nothing ticked sends nothing. If you tick a mode, the channel needs a destination: a valid email address for email, or an http or https URL for the webhook.

Destinations are stored encrypted and are never shown again. On the edit form the destination field is blank, with Configured beside it when one is saved. Leave it blank to keep the saved destination, or type a new one to replace it. To stop a channel, untick its modes.

late never alerts. It is the warning state inside the grace period.

One alert per incident

Muster sends one alert per channel per incident, then one recovered alert on the channels that alerted when the incident ends. It does not re-alert every minute while a monitor stays missed. A recovered alert goes only to channels that are still subscribed and that alerted for that incident.

Delivery

Every alert is a queued job, so a queue worker has to be running for anything to be sent. Each delivery is tried up to three times, with waits of 10 and then 60 seconds between attempts. A delivery ends in one of these statuses:

On a Scalpels-managed installation, the default Scalpels mailer delivers alert emails without additional configuration. Standalone installations use their configured Laravel mailer: delivery mailers are accepted when they are defined in the application's mail configuration, while non-delivery mailers such as log and array, and undefined mailers, are rejected. See Configuration.

Webhook alerts need no mail configuration.

Webhook requests

Muster sends a POST with a JSON body to your URL. It allows 3 seconds to connect and 10 seconds for the request, and it does not follow redirects. Any response other than a 2xx counts as a failed attempt, so point it at the final URL and return 200.

The body looks like this:

{
  "event": {
    "id": 412,
    "transition": "missed",
    "occurred_at": "2026-10-08T03:15:00.000000Z"
  },
  "monitor": {
    "id": 7,
    "name": "Nightly backup",
    "last_check_in_at": "2026-10-07T03:01:12.000000Z",
    "next_due_at": "2026-10-08T03:00:00.000000Z"
  }
}

transition is missed, recovered or non_zero_exit. The request carries no signature header, so treat the URL itself as the secret.

Alert emails contain the same facts and carry no links.

The weekly digest

Once the instance has at least one monitor, Muster emails a digest every Monday covering the previous complete UTC week, Monday 00:00 to Monday 00:00. It is generated at 00:05 UTC on Monday and sent from the queue.

The digest goes to every active user on the instance with a real email address. It lists:

• the number of monitored commands;
• monitors that went Missed during the week;
• runs that ended in a non-zero exit, with the exit code;
• monitors that are Still missed.

A week with no failures still sends an email, saying all clear. The digest includes each monitor's command where there is one, and links back to Muster using the app's own URL.

The digest needs both a real mail transport and a durable queue. Muster refuses to publish digests on the in-process queue drivers sync, deferred, background and null. The managed queue Scalpels provisions is durable.