# How SMS & voice alert billing works

Some alert channels have a real per-message cost. Here's how that cost is calculated and what to do when your
balance runs low.

## What's billed and what's free

- **Email, webhooks, and the chat/bot/push channels** (Slack, Teams, Telegram, Discord, Viber, Mattermost, web
  push, PagerDuty, Opsgenie, Pushover, Pushbullet) are **free** - they don't draw from any balance.
- **SMS and voice calls** draw from your account's **SMS credit balance**, counted in segments as below.
- **WhatsApp is designed to bill the same way as SMS** (same segment/encoding math, from the same credit
  balance) once it ships - it isn't a free channel, even though it isn't yet creatable for any account (see
  [WhatsApp](/alerts/channels/whatsapp/)).

A contact's per-message cost is exposed on the API as `sendCost` (`GET /contact/{id}` - present only for `sms`
and `voiceCall` contacts, omitted for every other type) - the price per segment for that specific contact,
before the segment/multiplier math below is applied.

## Monthly SMS allowance

Paid plans include a **free monthly SMS allowance** - a number of SMS credits refreshed each billing cycle before
any paid balance is drawn down. Once the free allowance for the month is used, further SMS/voice alerts draw from
your paid credit balance.

## How a message is counted - segments

An SMS isn't billed as "one message" flat - it's billed by **segments**, based on the character count and
alphabet used:

| Encoding | Used when | Single segment | Each extra segment |
|---|---|---|---|
| GSM-7 / Latin | Every character in the message has a code point under 256 (plain Latin text, digits, common punctuation) | 160 characters | 153 characters |
| UCS-2 | The message contains even one character at code point 256 or above (Cyrillic, Arabic, emoji, and other non-Latin scripts) | 70 characters | 67 characters |

A message longer than one segment's worth of characters is split and billed as multiple segments (segment count
= total length divided by the extra-segment size, rounded up). This is why an alert with a longer error
message, a non-Latin monitor name, or an emoji can cost more than one credit - keeping monitor and contact
names in plain Latin text keeps messages in the cheaper encoding.

On top of the segment count, a **2x multiplier** applies to the whole message whenever it contains any
character at code point 256 or above - each segment of that message is billed at double the normal per-segment
cost, in addition to UCS-2 already fitting fewer characters per segment. This compounds the cost of non-Latin
monitor names, error messages, or emoji even further than the segment table alone suggests. A message that is
entirely Latin/digits/punctuation is never multiplied, however long it is.

Voice calls are billed by the **same per-segment, text-length math as SMS**, applied to the text of the spoken
script - not a flat per-call price. A longer or non-Latin script costs more, the same way a longer or non-Latin
SMS does.

## Do it with the API or MCP

Billing itself isn't a setting you configure - it's a consequence of the contact type and the message text.
The one thing you can read is the per-segment price for a specific contact:

```
GET /contact/{id}
```

The response's `sendCost` field (present only for `sms`/`voiceCall`) is the price per segment before the
segment-count and 2x multiplier above are applied. There's no MCP tool that returns account balance or segment
pricing directly - `get_account`/`get_account_usage` cover quota and package limits, not the SMS credit ledger.

## Low balance

When your SMS credit balance runs low, HostTracker sends a low-balance warning email so you can top up before
SMS/voice alerts start failing. Top up from **Billing** in your account.

## Limits and gotchas

- There is no per-message price cap - a sufficiently long, non-Latin message can cost several segments at the
  doubled rate. Keep monitor/contact names and any custom text in Latin characters if cost predictability
  matters more than the exact wording.
- The free monthly allowance and paid balance are pooled at the **account** level, not per contact - every SMS
  and voice contact on the account draws from the same balance.
- A send that would exceed the balance fails silently from the recipient's point of view - nothing is queued or
  retried once funds run out; top up and the next scheduled check's alert goes through normally.

## Related

- [SMS](/alerts/channels/sms/) - [Voice call](/alerts/channels/voice/)
- [Account & billing overview](/account/overview/)