Notification preferences
Mute the email events you don't want. Default is everything on.
bichito sends you email notifications for events that affect your hives. The defaults assume you want every signal — you can mute any individual event from /me/settings/notifications.
Available events
| Event | Triggers when |
|---|---|
bug.created | A new bichito arrives in any of your honeycombs. |
bug.commented | Someone comments on a bichito (currently only your own comments since hives are single-user). |
bug.assigned_me | Someone assigns a bichito to you. |
Each row in the settings page has an on/off toggle. The change saves immediately; no "Save" button.
Default behaviour
- For brand-new accounts, every event is on — we don't seed rows in the DB for "default" preferences. Read-side helpers treat a missing row as enabled.
- The first time you toggle an event, we persist a row for it. From then on, it's the source of truth for that event.
- Re-enabling an event you previously muted just flips the row back to enabled — no events are replayed.
Where these emails come from
We use Resend for transactional email. The From: is bichito <noreply@bichito.dev>. Replies don't go anywhere — the address is unmonitored. If you want to discuss a report, do it from the dashboard's comment thread (which doesn't email back, by design — that loop is for your team only).
Per-honeycomb extra recipients
Beyond your own preferences, each honeycomb can list extra addresses that receive bug.created regardless of the global mute. See Notification emails. Those addresses don't see other event types — they're alert-only.
Unsubscribe link
Every email carries an Unsubscribe link in the footer that mutes the corresponding event. One click, no login required, idempotent. Useful when an email arrives at 3am.
Webhook alternative
If email is the wrong channel for you, register a webhook for bug.created and route it to Slack / Discord / your on-call paging system. The two channels are independent; muting email doesn't affect webhook delivery.