Email notifications

Charcha can email you when a comment arrives. It is off until you configure it, and a deployment that never does still collects every comment in the moderation queue.

The email is a prompt to come and look. It is never the record. If a notification is dropped, delayed or fails to send, the comment is still in your queue exactly as it would have been, so nothing you are told about by email is something you could only have learned by email.

What it takes

Three values, and the feature stays off until all three are there.

Value	What it is	Where you set it
RESEND_API_KEY	Your key from Resend	A secret on the Worker. Setting a secret
Send notifications to	Your own inbox	The Setup tab in your dashboard
Send them from	An address on a domain you verified with Resend	The Setup tab

Only the key is a credential, so only the key is a secret. The two addresses are ordinary settings that live in your database, and the Setup tab has a field for each. That was not always true: they used to be CHARCHA_NOTIFY_TO and CHARCHA_NOTIFY_FROM, and a deployment still running on those keeps working. The tab says so, and offers to take them over. Save the addresses there and you can delete the two secrets.

A key with no recipient has nowhere to send, and Charcha stores no owner address anywhere else to guess one from. Setting one or two of the three leaves the feature off rather than half on, and the Setup tab reports it as off.

The sending address is the thing that goes wrong

It has to be on a domain you verified with Resend, under the same account the key belongs to. Mail from an unverified domain is refused by Resend before it goes anywhere.

The reason this is worth its own heading is what that refusal looks like from your side: nothing. No comment is lost, no error reaches your dashboard, and your queue fills up normally. It is indistinguishable from the feature being switched off, which is the same failure a mistyped key produces. So the two things worth doing are checking the address for typos before you save it, and checking your Worker’s log if the emails never start.

Your own inbox is the only address Charcha ever mails. There is no unsubscribe link, because there is nobody to unsubscribe but you. Clearing the recipient field is how you switch the emails off again.

The sender name

Optional, and it is what your mail client shows instead of the bare address.

It goes into the From header, so Charcha refuses a name carrying any of the characters a mail parser reads as structure: angle brackets, quotes, a backslash, an @, a comma, a colon, a semicolon, or round or square brackets. A full stop is allowed, because maya.build comments is a name people want. A name longer than 64 characters is refused too. A display name that reads Charcha <security@bank.example> renders in a mail client as a sender that is not the sender, which is the whole of why this field is checked rather than escaped.

A refusal names the character it refused, in the dashboard, at the moment you save. Nothing is truncated quietly: a sender name that silently became half a name is exactly what nobody notices in their own inbox.

Why a busy morning does not spend your whole allowance

Every comment is a potential email, and the cost of one is yours rather than Charcha’s. It lands on your Resend quota and on your sending domain’s reputation. Resend’s free plan allows 3,000 emails a month and is limited to 100 a day (pricing, checked 2026-07-25), so two hundred comments arriving in an afternoon would spend the day’s allowance and then drop the notifications about the real comments that followed.

So sends are bounded. Five may go out back to back, which covers an ordinary busy morning without any throttling at all, and after that one token refills every fifteen minutes. That is four an hour and 96 a day in steady state, chosen to sit under the free-plan cap rather than picked for feel.

When sends have been suppressed, the next email that does go out says how many arrived while it was quiet. You are told that you missed some, rather than being left to notice.

The honest limitation is that the bucket lives in one running copy of your Worker rather than in a shared counter, so several copies running at once can each send at that rate. A shared counter would mean a database write per comment, which is the budget a comment flood is already attacking. The bound leans in the useful direction anyway: a quiet site gets a fresh copy with a full bucket, so every real comment mails, and a flood is exactly the case where a small number of hot copies makes the bucket bite.

When nothing arrives

Check the Setup tab first. If it reports email notifications as off, one of the three values is missing or misspelled and nothing else will explain it.

If the tab says the feature is on and no email has arrived, the values are present and one of them is wrong. The sending domain is the usual answer, and the key is the other one.

Your Worker’s log carries the rest. A notification that fails to send says so there, is not retried, and cannot yet be surfaced anywhere the dashboard can show you. A line carrying event: "notify_config" means nothing could be deferred past the response on that invocation, so no notification was attempted at all. Health and monitoring has the other lines worth recognising.