Limits and control
How much can go out, where to look at what happened, how to keep watch.
The limits
| Limit | Value | What happens if you go over |
|---|---|---|
| Sends per key | 60 a minute | 429 RATE_LIMITED |
| Login attempts | 10 every 5 minutes | 429 RATE_LIMITED |
| Recipients per send | 50 | 400 VALIDATION_ERROR |
| Attachments | 5 files, 5 MB each | 413 FILE_TOO_LARGE |
| Request size | 30 MB | 413 from the proxy |
| Subject length | 998 characters | 400 VALIDATION_ERROR |
Sends are counted per key and not per IP address: whoever integrates sits behind a single outbound IP, and a limit per IP would hit all of their applications at once. When there is no key, sending from the panel for instance, it falls back to the address.
The limit is held in memory by the process, so with several replicas it multiplies by their number.
History, logs and statistics
The history lists the sends with recipients, subject, template, project and outcome.
There are three states: pending when the row is created and the outcome is still unknown,
sent, and failed with the error message next to it.
The logs record the application events, sends included, and are filtered per user. SMTP passwords, keys and tokens never get in there, not even in the metadata.
The statistics aggregate sends by status, over time and by template usage, per project.
The API exposes the history on GET /api/emails, paginated by cursor: before is the id of
the last row already seen, and there is no offset, because with rows being born all the time
the second page of an offset skips or repeats whatever arrived in between. It needs a panel
session, not a project key.
The probes
GET /health says that the process answers, and it is the right question for an automatic
restart.
GET /ready says that it can serve traffic: it really queries the database and answers 200
with {"status":"ok","database":"up"}, or 503 if the database does not answer.
They are public and unauthenticated, and external monitoring is what queries them.
What monitoring does not see
That the mail actually arrives. The probes say that the application answers and that the database is there, not that the SMTP server downstream is delivering. The only way to notice is a periodic send towards a mailbox that somebody watches.