Adding a host to Zabbix is a one-minute job with a form that has about a dozen fields, most of which are optional. The reason it is worth more than a minute of your attention is that three of those fields are decisions rather than settings - they are cheap now and expensive to change once you have several hundred hosts depending on them.
This walks the form, says what each field actually controls, and flags where the default will cost you later.
Data collection → Hosts. On a clean installation there is
exactly one host there already - Zabbix server, which the server uses to
monitor itself. Leave it alone; it is a useful canary and its template is a decent
reference.
There is a host wizard, and there is Create host. The wizard is fine. The form is worth understanding anyway, because it is what you will be looking at every time something does not collect.
Host name is the identity. It is what the API uses, what appears in trigger expressions, and what an auto-registration or discovery action will match against. Visible name is an optional alias shown in the UI instead.
The pairing exists for estates where the real hostname is machine-generated -
vm-prd-eu-0417a - and unreadable in a problem view at three in the
morning. Set the technical identity as the host name, the human label as the visible
name, and both audiences are served.
Pick a naming convention before the tenth host, not the hundredth. Zabbix does not care what you choose, but you will filter, group, and write trigger expressions against these strings for years. Renaming later is possible and tedious, and it breaks anything that referenced the old name.
Host group is mandatory - every host belongs to at least one, and a host can be in several. It is tempting to treat groups as tidy folders and move on.
They are the permission boundary. In Zabbix you grant users and user groups access by host group, so how you group hosts decides who can see and change what. A group structure that mirrors your org's access needs - by team, by environment, by customer - is doing real work. One that mirrors a rack diagram is not, and you will end up creating a second, overlapping set of groups when someone asks for environment-scoped access.
Because a host can sit in several groups, you do not have to choose. A database
server can be in Linux servers, Production and
Team: Data at once, serving discovery, environment filtering and
permissions independently.
Optional on the form, and the reason the host does anything at all. A host with no template and no items is an entry in a table - Zabbix will happily create it and collect precisely nothing, which is the single most common "why is my host not working" answer.
You can link templates now or later. Later is fine. Templates and items covers what to link and, more importantly, where to put anything custom.
An interface tells Zabbix where to reach the host for a given protocol. Which type you need follows entirely from how you plan to monitor it.
| Interface | Use when | Needs |
|---|---|---|
| Agent | You can install the Zabbix agent - Linux, Windows, most servers | IP or DNS, port, and the agent running and reachable through the firewall |
| SNMP | Network devices, printers, UPSs, anything you cannot install software on | IP or DNS, port, SNMP version, and a community string, or the fuller credential set for v3 |
| JMX | Java application monitoring | IP or DNS and port, plus the Zabbix Java gateway running |
| IPMI | Out-of-band hardware health from a BMC | IP or DNS, port and IPMI credentials on the host |
You can add several - a server with both an agent and an IPMI controller wants two.
Plenty of hosts need no interface at all. These four are not the whole of Zabbix monitoring. HTTP agent items carry their own URL, calculated and dependent items derive from data already collected, and trapper items are pushed in from outside. A host built entirely from those is legitimate and interfaceless, which surprises people who assume the form is lying to them.
Server, proxy, or proxy group. On a small estate the answer is the server and you can stop reading.
A proxy collects on the server's behalf, which you want when the host is behind a firewall or NAT, on a remote site, or when you are spreading collection load. A proxy group puts several proxies behind one assignment so collection is load-balanced across them and survives one of them failing.
This is the field most worth getting right at creation time. Moving hosts between proxies later is entirely possible, but it is a bulk operation people put off, and the estates that end up with one overloaded proxy and three idle ones got there one default at a time.
Click Add. If you linked a template with items, data starts arriving on the items' own schedule - not instantly, which is the second most common "it is not working" report. Give it an update interval or two, then check Monitoring → Latest data filtered to the host.
If nothing arrives, the order to check is: does the host have items at all (a template linked?), is the interface right for those items' type, and can the server or proxy actually reach that address on that port. In that order, because the first one is free to check and is the answer more often than anybody admits.
Under five minutes, straight through the form.
One thing to know about the video. It was recorded against a pre-release build of Zabbix 8.0, which was still in alpha at the time and is not released yet - it is planned for Q3 2026. The current versions are 7.4 and 7.0 LTS. The host form is materially the same across all of them, so nothing here is wrong, but the version number in the corner of the screen is ahead of what you can install.
Host groups that mean nothing, hosts monitored directly that should be behind a proxy, naming that made sense to somebody in 2019. It is all fixable, and it is much easier to fix with a plan than one host at a time. If you are staring at a Zabbix install you did not build, that is a good thing to talk through.