> 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-details.md). # Server details Open a server from the [Servers page](/organizations/servers-page.md) — click its name, or anywhere on its row. The server's own pages carry its name at the top, its current power status, and a row of tabs. | Tab | What it covers | | ----------------- | ------------------------------------------------------------------------------ | | **Overview** | Names, hardware, operating system, location and deployment details. | | **IP Management** | IP addresses, gateways, netmasks and reverse DNS. | | **Usage** | [Traffic, CPU and memory graphs](/organizations/server-usage.md). | | **Alerts** | [Traffic alerts](/organizations/server-traffic-alerts.md). | | **Labels** | [Your own labels](/organizations/server-labels.md) for grouping and searching. | | **Contract** | Costs, dates and renewal. | ## Power status Next to the server's name, a **Power status** pill reports the chassis: | Reading | What it means | | ---------------- | ---------------------------------------------------------------------------------------------------------------- | | **Online** | The server is powered on. | | **Offline** | The server is powered off. | | **Check failed** | We asked the server and it didn't answer. The *check* failed — this doesn't necessarily mean the server is down. | | **Unconfirmed** | The power state couldn't be determined: it hasn't been probed, or the last reading is too old to vouch for. | ## Power actions Buttons beside the power pill control the chassis. Which ones appear depends on the current reading — an *Online* server is offered **Restart**, **Shutdown** and **Force power off**; an *Offline* one is offered **Start**. When the state is *Check failed* or *Unconfirmed* all four are offered, and we let the server decide. | Action | What it does | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Start** | Powers the server on. | | **Restart** | Restarts by cutting power. The operating system is **not** shut down first, so unsaved data may be lost. If the server is still reachable, restart from the operating system instead. | | **Shutdown** | Asks the operating system to shut down cleanly. This can take a few minutes, and an unresponsive server may ignore it. | | **Force power off** | Cuts power immediately, without shutting the operating system down. Unsaved data may be lost. Use **Shutdown** first unless the server is unresponsive. | Each action asks you to confirm and names the server in the dialog. The pill then shows progress — *Starting*, *Restarting*, *Shutting down*, *Powering off* — and reports the result once the new state is observed. {% hint style="warning" %} **Restart** and **Force power off** are the equivalent of pulling the plug. Reach for **Shutdown** whenever the operating system is still responding. {% endhint %} ### When an action can't be sent | Message | What to do | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | *Another power action is already running for this server* | Wait for it to finish, then try again. | | *A power action was just sent to this server* | Wait a moment and retry. | | *Power actions aren't available for this server right now* | Try again shortly. | | *You don't have permission to control this server* | Ask an administrator of your organization. | | *We couldn't confirm the … reached \* | The request may or may not have landed. The Console re-checks the power status; for a restart, check the status yourself before trying again. | ## Overview tab **Custom details** holds the two fields you set yourself: * **Custom name** — your own name for the server. It's what the Console shows in the server list and at the top of these pages. * **Project name** — a free-text note for your own reference. Click a field, or **Add a name** where one isn't set yet, to edit it. The remaining cards are read-only: | Card | Shows | | ---------------------- | --------------------------------------------------------------------------------------------------------------- | | **Server details** | Server name, rack, category, operating system, and the address you reach the server on with a link to the rest. | | **Hardware** | Brand, model, processor, memory and hard disk. | | **Deployment Details** | Environment, the fleet the server is reserved for and used by, deployment mode and deployment profile. | | **Location** | The data centre the server sits in. | FlexMetal servers also get a card linking to the [FlexMetal API](/compute/flexmetal/api.md) documentation, and show the **server UUID** that API calls address them by. Every server can be reached through the Host API. ## IP Management tab Every IP address assigned to this server gets **its own card**, showing how that address is configured and the reverse DNS name it answers to. Every value has a copy button. | Field | Shows | | --------------------- | ------------------------------------------------------------------------------------ | | **Gateway** | The address's gateway. | | **Netmask** | Its netmask. IPv4 only — an IPv6 card shows the prefix instead. | | **Prefix** | The prefix length, for example `/26`. | | **VLAN ID** | The VLAN it belongs to. | | **Interface** | The network interface it's bound to, where the platform reports one. | | **Reverse DNS (PTR)** | The reverse DNS record. Omitted entirely on a private address, which can't hold one. | A chip on each card says what kind of address it is: * **Management** — the out-of-band address. This reaches the server's management interface, not your workload. * **Private** — reachable only from inside your own network. An address with neither chip is a public address your workload answers on. A **DNS resolvers** card below lists the resolvers the server is configured with. {% hint style="info" %} **Reverse DNS can't be changed here yet.** Set it with the reverse DNS endpoint of the i3D.net API — the tab links to the reference. {% endhint %} ## Contract tab Cards covering the commercial side of the server: **monthly cost**, **traffic overuse fee**, **cancellation term**, **contract start** and **end dates**, **invoiced until**, and **contract renewal**. Dates the platform holds no value for show as a dash. **How the server is billed.** Most servers aren't priced individually, so the cost card says how this one is actually billed rather than showing a price: | Reads | Means | | ----------------------------- | --------------------------------------------------------------------------- | | An amount | Priced individually. Per month, excluding VAT, billed to the named account. | | **Part of your agreement** | Billed under your agreement with i3D.net, not on its own. | | **No monthly charge** | Provided without a monthly charge. | | **Billed through FlexMetal** | Covered by your FlexMetal arrangement. | | **No monthly cost on record** | Ask support or your account manager what this server costs. | {% hint style="warning" %} **Cancel by is not the same as the contract end date.** A committed term renews a full notice period *before* it ends, so cancelling on the end date is too late — you'd already be bound for another term. The **Cancel by** card shows the actual deadline, on your own clock (for example *September 24, 2026 — 11:59 PM, in 6 days*). That's the date to act on. {% endhint %} Where a server can't be cancelled on its own — one billed under a wider agreement, a virtual machine, or a FlexMetal server — the tab explains why and points at the right route to change it. Contact support if you're unsure; you don't need an account manager to cancel. ## Related topics * [The Servers page](/organizations/servers-page.md) * [Server labels](/organizations/server-labels.md) * [Traffic alerts](/organizations/server-traffic-alerts.md) * [Server usage](/organizations/server-usage.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-details.md?ask=&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.