---
title: "Email Notifications"
description: "Who gets told when a deployment fails, an app turns unhealthy, or the platform steps in."
---

Email is the third way Miget tells you something happened, alongside [webhooks](/monitoring/webhooks) and [Slack](/monitoring/slack). It needs no setup - it is on by default - and unlike the other two it reaches a person rather than an endpoint.

Choose what arrives under **Settings → Notifications**, in the **Applications** group.

## Who receives what

Mail is addressed by responsibility, not broadcast to everyone in the workspace.

| Notification | Goes to |
| --- | --- |
| Deployment failures | Whoever started that deployment |
| Successful deployments | Whoever started that deployment |
| Health alerts | Workspace admins |
| State changes | The workload's owner |
| Critical alerts | Workspace admins, and the owner where there is one |

A deployment started by a push is attributed to the pusher where their email matches a workspace member; otherwise it falls back to the application's owner.

## The switches

**Deployment failures** — a deployment you started did not finish. On by default.

**Successful deployments** — the same, for the ones that worked. **Off by default**, because on an active application this is the noisiest mail Miget sends.

**Health alerts** — crash loops, failing health checks, expiring certificates, and observability ingestion crossing its limit. Sent to workspace admins, since these usually need somebody with the access to act.

**State changes** — an application, service, or add-on started, stopped, or failed. Covers workloads of every kind, not applications alone.

**Critical alerts** — blocked or deleted applications, and billing. **Always on and not switchable**: these either cost money or stop your workloads, and neither is something to find out about late.

## What is not switchable

Access and billing mail is never optional: invitations, ownership transfers, access granted or revoked, subscription and payment changes, expiring API tokens, and resource lifecycle warnings such as inactivity or deletion for non-payment. Turning those off would let somebody lose a resource quietly.

## Next Steps

<CardGroup cols={2}>
  <Card title="Webhooks" icon="webhook" href="/monitoring/webhooks">
    The same events as a signed POST to your own endpoint.
  </Card>
  <Card title="Slack" icon="slack" href="/monitoring/slack">
    The same events, posted to a channel.
  </Card>
</CardGroup>