Skip to content
Facteur
FRGet started

Quotas and alerts

One inbox’s quota should never depend on another’s

Elsewhere, isolating quotas requires an Enterprise plan. Here it is included from twelve euros a month, because it is the condition for a team to work in peace.

Today’s quotas

4 inboxes
  • ci-nightly4,120 / 5,000
  • e2e-signature7,640 / 8,000

    90 % alert sent

  • manual-staging240 / 2,000
  • load-test3,000 / 3,000

    limit reached, messages refused

infra/quotas.tsTypeScript
// Ceilings live in the API, so they live in your IaC.
await facteur.inboxes.update('j3k9x2mq', {
  quota: {
    daily: 5_000,       // an infinite loop stops here
    monthly: 80_000,    // the month's budget
    // 'reject': CI stops dead, with an explicit SMTP refusal.
    // 'alert' : we warn, we let it through.
    onExceed: 'reject',
  },
});

Detail

What you can set

Available from the first paid plan

€12/month

Quota isolation is not a commercial negotiation lever. It is the minimum for a team to share an account without getting in each other’s way, so it is included from the Solo plan.

Daily and monthly limits

Both, independently, per inbox. The daily limit protects against infinite loops; the monthly one protects the budget.

You choose the behaviour

reject | alert

On overage the inbox refuses messages at the SMTP level, and your test fails cleanly with an explicit error code, or it keeps accepting and merely alerts. Whether the inbox serves CI or a customer demo, the right choice differs.

Progressive alert thresholds

50 · 75 · 80 · 90 · 100 %

One alert per threshold crossed, never twice for the same one, and at most four thresholds. Beyond that they are reminders, not alerts.

Told where you are already looking

Up to three destinations per alert: an address, a Slack channel, a Discord channel, in whatever combination you want. The alert carries the figure, the organisation, the workspace and the inbox it concerns, and a link to the usage screen.

Usage per inbox

The dashboard answers “who used my quota”, not just “how much did I use”. Per inbox and per day.

Global spending cap

A maximum beyond which we stop billing pay-as-you-go. A surprise bill is a design defect, not a fact of life.

Ceilings are driven by API

PATCH /v1/inboxes/{id}

The daily ceiling, the monthly one and the behaviour on overage are set with an API key: your quotas live in your repository, not in the memory of whoever last clicked. Where alerts go is set from the application, and only there. A stolen key could otherwise silence every alert an account has, and the symptom of a silenced alert is silence.

And when it overflows

Three ways out, and you pick

Exceeding a quota is a normal event in a project’s life. It should not be an incident.

Option 1

A pack, right away

Two clicks, payment, capacity available within the second. Your subscription does not move by a cent.

Option 2

Pay-as-you-go takes over

Nothing to do, nothing breaks, billed on usage within your spending cap.

Option 3

We refuse, cleanly

An explicit SMTP rejection rather than a message swallowed in silence. Your test fails for the right reason, and you see it.

Take back control of your capacity

Per-inbox quotas, progressive alerts and a spending cap: included from the Solo plan, with no sales conversation.

Create a free accountHow to migrate