> For the complete documentation index, see [llms.txt](https://docs.i3d.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.i3d.net/organizations/server-traffic-alerts.md).

# Traffic alerts

Go to a server's **Alerts** tab. A traffic alert tells you when a server's traffic reaches a percentage of what its contract includes, so you hear about it before you go over rather than on the invoice.

Add one alert per warning you want — for example one at 80% and one at 95%. Each fires **once per billing period**.

## Creating an alert

{% stepper %}
{% step %}

#### Open the Alerts tab

Open the server from the [Servers page](/organizations/servers-page.md) and choose **Alerts**.
{% endstep %}

{% step %}

#### Start a new alert

Click **Create alert**.
{% endstep %}

{% step %}

#### Set the threshold

Choose a percentage between **1** and **100**, using the slider or by typing a whole number.
{% endstep %}

{% step %}

#### Choose how you want to be notified

**Email** sends a heads-up. **Email and a support ticket** sends the same heads-up and opens a ticket with i3D.net, so you can reply and ask for more bandwidth before you go over.
{% endstep %}

{% step %}

#### Save

The alert appears in the table.
{% endstep %}
{% endstepper %}

## The alerts table

| Column             | Shows                                                                                                                               |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Alert at**       | The percentage that triggers the alert.                                                                                             |
| **Notify by**      | *Email*, *Support ticket*, or *Email and support ticket*.                                                                           |
| **Goes to**        | The address the notification reaches.                                                                                               |
| **Last triggered** | When it last fired. **Not this period** means it hasn't fired since the current billing period began — not that it has never fired. |
| **Created**        | When the alert was set up.                                                                                                          |

The ⋮ menu on each row edits or deletes the alert.

## Who gets notified

Alerts go to the contact on the **billing account this server belongs to** — not to whoever created the alert. The address is named in the dialog when you set the alert up, alongside its K-number.

{% hint style="warning" %}
**If a billing account has no email address on file**, no alert on it can reach anyone, and the tab says so at the top. Use **Need Help?** in the side menu to ask us to add one.
{% endhint %}

{% hint style="info" %}
A server can change billing account. An alert created before that still points at the account it was stamped with, which is why the dialog always names the K-number as well as the address.
{% endhint %}

## What the percentage is measured against

The threshold is a plain percentage of what your contract includes. Depending on your contract that resolves against a monthly volume or a committed rate — the alert itself doesn't take a view, it just compares against whichever applies to this server.

## Related topics

* [Server usage](/organizations/server-usage.md)
* [Server details](/organizations/server-details.md)
* [The Servers page](/organizations/servers-page.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.i3d.net/organizations/server-traffic-alerts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.