What Zabbix synthetic web monitoring with browser items checks
Zabbix browser items run scripted browser sessions on a schedule and report whether a multi-step journey completed, which is a check that host and service monitoring cannot make. The situation this addresses is common: the web servers respond, the database is healthy and CPU is flat, yet customers cannot sign in or finish checkout. An HTTP check confirms that a URL returns a status code and a process check confirms that a service is running, but neither proves that the login form accepts credentials, that the redirect after sign-in reaches the account page, or that the payment step shows its confirmation. Browser items close that gap by driving a real browser through the same steps a user takes and recording where the run stopped.
Teams usually need this for customer-facing logins, checkout flows, client or supplier portals and multi-step forms where front-end scripts, single sign-on redirects or session cookies decide whether the journey works. Plain HTTP or host checks are usually enough for static pages, a single health endpoint, or a failure that already shows up in server-side metrics such as error rates and queue depth. A practical starting point is to list the journeys by business impact, then ask for each one whether a broken step would be visible anywhere in current monitoring. If the answer is no, the journey is a candidate for a browser check. Expect scripts to need upkeep whenever the interface changes, so limit the first set to a few journeys that matter most.
The feature depends on an external WebDriver endpoint, such as a Selenium or ChromeDriver service, that Zabbix contacts to run each session. Someone on your team owns that endpoint, including its browser versions, network reachability from the Zabbix server or proxy that runs the item, and the compute it needs when several sessions run at once. Before you commit a customer-facing journey to browser items, confirm whether the item type is still marked as experimental in the version you run, and check the Zabbix documentation and release notes for that release. Treat the answer as a gate for production use, not as a detail to settle later.
Design the test account and its data before writing the script. Use dedicated synthetic accounts that are not tied to a person, keep them out of reporting and marketing lists, and store their credentials as protected macros rather than in script text. Journeys that require multi-factor authentication or one-time codes need a deliberate approach, because a check that cannot complete the second factor will fail for reasons unrelated to the application. Decide who can change these accounts, and record which journey steps are allowed to create data, such as a test order, and how that data is cleaned up.
Before relying on the checks, ask the vendor and your own platform team to confirm the supported WebDriver and browser versions for your Zabbix release, the poller capacity you need for the number of journeys and their run frequency, how timeouts are applied and reported, whether screenshots are captured on failure and where they are stored, and how a failed run reaches an alert. Then run the journeys against a staging copy of the application for an agreed period, and compare the results with what users report. Only move a journey to production alerting once it has produced reliable results against a known fault.
Which browser item settings fit which journey
This table compares the five browser item settings a team chooses for each journey, showing when each fits, what it adds to poller and endpoint load, and how it fails when set too aggressively. Read each row against the journey it covers, since a login flow and a checkout flow rarely need the same answers. The main takeaway is that script scope and run frequency drive most of the load, so start with the fewest steps and the longest interval that still catches the failures you care about. Confirm exact field names and limits in your Zabbix version's documentation before you build.
| Setting | When it fits | Poller and endpoint cost | What goes wrong when set too aggressively |
|---|---|---|---|
| Scripted steps and scope | Login plus one critical transaction per item, limited to the steps that prove the journey works. | Each step adds browser time on the poller and session load on the Selenium or ChromeDriver endpoint. | Long scripts mix unrelated failures, so one broken control fails the whole journey and hides the cause. |
| Check interval | Journeys that change with releases or matter during business hours. Confirm the field and its allowed range in your version. | Each run opens a full browser session, so load grows with frequency and with the number of journeys. | Frequent runs queue on busy pollers and hit the application often enough to look like an outage. |
| Timeout values | Flows that wait on slow identity providers or third-party pages. Base timeouts on measured step times. | Long timeouts hold poller capacity while a stalled browser waits for a page that never loads. | Short timeouts report slow but working pages as failures, while long timeouts delay the alert. |
| Screenshot capture | Customer-facing journeys where a reviewer needs to see the page at the point of failure. Confirm the capture behavior in your version. | Image capture and storage add work to every run, and images accumulate in item history. | Capturing on every passing run fills storage and slows the item without adding evidence. |
| Credentials and test accounts | Login journeys that need a dedicated, non-personal test account with limited rights. | Little runtime cost, but each journey needs its own account and a rotation process for its password. | A personal password in the script breaks when its owner changes it and exposes that account. Use secret macros where your version supports them. |
How a browser item drives a Selenium or ChromeDriver session
A browser item runs a user journey in a remote browser on each check, so every run depends on several components that your team operates. The sequence starts when the Zabbix server, or a proxy that the item is assigned to, reaches the item's scheduled check. Zabbix then sends the step commands to a WebDriver endpoint such as a Selenium server or ChromeDriver. The endpoint opens a browser session, which loads the application and performs the scripted actions: navigating, entering values, clicking and reading page content. When the steps finish, the outcome is stored as item data, and triggers evaluate that data like any other item value.
The team must run and maintain three things: the WebDriver endpoint, a browser build that matches the driver, and the scripts that describe each journey. Browser and driver versions must move together, and a browser update can break a session that worked the previous week, so test version changes in a staging check before they reach production. Confirm in the Zabbix documentation for your release which endpoints and browser combinations are supported, because that compatibility list is not covered by the material available for this page. Scripts also need an owner. Label, layout or authentication changes in the monitored application will fail a journey, and the runbook should name who reviews the script after each application release.
Where the check runs determines what it measures. The browser session reaches the application through the network path, DNS resolution, certificate trust and firewall rules of the host running the endpoint. If that host sits in a different network zone from the users the journey represents, a failure may reflect the endpoint's path rather than the application. For user-facing journeys, place the endpoint in the same network segment that users reach the application from, and confirm that name resolution and certificate trust work from that host. If a proxy is closer to the application, confirm with Zabbix whether browser items run on the server or the proxy in your version, and check that the endpoint is reachable from that node.
Several decisions shape the setup before any script is written. Choose between a single ChromeDriver instance and a Selenium server with multiple browser nodes, based on how many journeys must run concurrently and who else shares the endpoint. Decide where the endpoint runs (container or virtual machine) and who patches it. Store test account credentials as Zabbix secret macros or in your vault, and agree how multifactor prompts are handled for the test account before writing steps that depend on login. Ask your Zabbix support or documentation how a browser item behaves when the endpoint is unreachable, and whether proxy groups redistribute browser items when a proxy goes offline, since proxy load balancing is documented for monitored hosts.
Plan for failures that look like application failures. An unreachable endpoint, an expired browser build or a blocked outbound path can all fail a journey while the application is healthy. Create separate triggers for endpoint and application problems where your version allows it, and run each journey manually against the endpoint and inspect the returned item data before enabling alerts. Record the expected output of each step so that the first alert after a change can be checked against a known baseline.
Sizing pollers for Zabbix synthetic web monitoring
Browser items are heavier than standard item checks, so the pollers that run them depend on several load drivers working together. The cards below cover what adds load, where checks run, how timeouts affect other monitoring, and how to confirm settings before you rely on them.
Journeys and run frequency
Count every login flow and key user journey you plan to test, then multiply by how often each one runs. Each run opens a browser session, so a journey that runs every minute consumes far more capacity than one that runs every hour. Before you add journeys or shorten intervals, confirm which flows are business-critical, because each addition increases concurrent demand on the endpoint and the pollers that drive it.
Steps and waits per script
Each step in a browser script adds page loads, element lookups and waits, and every wait keeps a session open for longer. Review scripts for fixed sleeps, which hold a session open even after the page is ready, and replace them with conditions that wait for a specific element to appear. Count steps per script alongside journey count, since one long script running often can cost more capacity than several short ones.
Parallel browser sessions
The Selenium or ChromeDriver endpoint limits how many browser sessions can run at once, and that limit caps how many journeys can finish on schedule. Confirm the concurrency your endpoint and browser versions support, along with the memory and CPU each session needs on the host. A session held by one slow journey is unavailable to others until it closes, so plan around peak concurrency measured during busy periods.
Server or proxy placement
Browser checks can run on the Zabbix server or on a proxy. A proxy placed near internal applications keeps browser load out of the central server and can reach targets behind a segmented network. Confirm where your Zabbix version runs browser items before you design the proxy layout. From Zabbix 7.0, proxy groups redistribute monitored hosts when a proxy goes offline, but a failed proxy also removes its browser capacity until failover completes.
Timeouts and poller availability
A slow page holds its poller until the item timeout expires, and during that time the poller cannot run other checks. One slow login flow can therefore delay unrelated items assigned to the same poller. Set browser item timeouts so a stuck journey fails clearly, and keep browser items apart from high-volume standard checks where your version allows it. Test how the monitoring behaves when a target responds slowly, and watch for gaps in other items during that test.
Measuring session duration
Run each journey in a test environment that resembles production, and record how long each session takes from start to finish, including page loads and waits. Use the slowest expected run, with a margin above typical runs, as the input for timeouts and capacity. Confirm poller and timeout parameters in the documentation for your exact Zabbix version. Do not copy values from other deployments, because network latency, target applications and endpoint hardware differ.
Setting up the first login journey step by step
This sequence takes a team from a confirmed Zabbix version to a browser item that signs in with a dedicated test account, alerts on failed or slow journeys, and has been reviewed against live data. Each step ends with a check you can run yourself, so work through them in order because later steps depend on the endpoint and the verified script.
Confirm the Zabbix version and support window
Check which Zabbix line you run and how long it receives support before you build anything. The platform team confirms this against the Zabbix life cycle policy: for example, Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029, while Zabbix 6.0 LTS limited support ends on 28 February 2027. Done when the version, the support end date and the upgrade plan are recorded in the project file.
Stand up a WebDriver endpoint
The infrastructure team deploys a Selenium or ChromeDriver style WebDriver endpoint on a host that both the Zabbix server or proxy and the monitored application can reach. Place it on a network segment close to the checks where possible, and restrict which systems can reach its port. Set the WebDriver URL in the Zabbix configuration as the documentation for your version describes. Done when a simple request from the Zabbix host receives a session response from the endpoint.
Prepare a dedicated test account
The application owner creates a synthetic user that exists only for monitoring. Give it a role limited to the login journey, with no administrative rights and no ability to change business data, and use a non-production environment where the login path matches production. Store the password in the secret store your team already uses, never in the script, and record who owns the account and how its password rotates. Done when the account signs in manually and the application's role view confirms its limited rights.
Write and run the first login script
The monitoring engineer writes a short browser script that opens the login page, enters the test credentials, submits the form and confirms a known element on the landing page. Keep it to the steps needed to prove that sign-in works, and avoid extra navigation that adds failure points. Run the script by hand against the WebDriver endpoint before adding it to Zabbix. Done when the manual run returns the expected landing element and the endpoint log shows the session closing after the run.
Add the browser item with timeouts and interval
In the host configuration, create the browser item with the verified script, a polling interval that matches how quickly your team needs to learn of a failed sign-in, and timeouts long enough for the slowest normal page load. Set these values from the manual run times you observed, with the headroom your team agrees on. Check poller capacity against the number of browser items, because each run occupies a poller while it executes, and confirm sizing guidance in the requirements documentation. Done when the item reports successful values in latest data on its first scheduled cycles.
Add triggers for failed and slow runs
Create one trigger that fires when the item reports a failed run and a second that fires when a run exceeds the completion time your team set for the journey. Route both to the on-call channel with the host and the journey name in the message. Test each trigger on purpose: enter a wrong password for the test account to produce a failure, and confirm the alert arrives where expected. Done when the deliberate failure opens a problem and the next successful run resolves it.
Review results over an agreed period
Over an observation period agreed with operations, the team reviews run results, timing trends and any false alarms caused by application maintenance or test account lockouts. Adjust timeouts, the polling interval or script waits based on that evidence, and check the WebDriver endpoint logs for sessions that did not close, since those point to cleanup problems. Confirm the experimental status of browser items for your version before relying on them for alerting. Done when the team approves the alert thresholds and the logs show each session ending after its run.
Securing test credentials and the WebDriver endpoint
Browser items log in to your applications and drive a real browser, so the test account and the WebDriver endpoint become privileged components of the monitoring design. The cards below cover how to isolate and rotate the credential, keep it out of logs and screenshots, lock down the browser endpoint, and settle how MFA-protected logins will be handled before any script is written.
Isolate and least-privilege the test account
Create a dedicated monitoring account in the application under test, not a shared user or an administrator. Grant only the permissions the login flow and key journeys need, and confirm that it cannot change data, approve transactions or reach other tenants. Ask the application owner to document what the account can access so the scope is reviewed, not assumed.
Store and rotate the password through secrets management
Keep the test account password in your organization's approved secrets store, not in Zabbix macros typed by hand, in script bodies or in configuration files on the Zabbix host. Agree with the secrets owner how the value is injected, who can read it, and how often it rotates, then confirm that a rotation also updates the monitoring item so checks do not fail silently after a password change.
Prevent credential exposure in logs and screenshots
Check that item values, Zabbix server and proxy logs, and browser console output never echo typed passwords, session cookies or tokens. Review how failed logins are reported, because error text can include the submitted value. Confirm the retention and access rules for the monitoring history, since its values may be visible to a wider audience than the application itself.
Treat the WebDriver endpoint as privileged
A Selenium or ChromeDriver endpoint can drive a logged-in browser on command, so it is a privileged system. Place it on a restricted network segment, allow connections only from the Zabbix server or proxies that run browser items, and disable any remote interface that is not needed. Verify the restriction with a connection test from outside the allowed sources.
Keep the browser and driver versions current
The browser and its driver must match in version and receive security updates on a planned cadence. Record which versions the endpoint runs, track the vendor's release notes for both, and schedule updates in a test window where the monitored journeys are re-run. An outdated browser is a security exposure in itself, and a mismatched driver causes checks to fail.
Control script edit rights and review screenshots
Limit who can create or change browser item scripts, because a script decides what is typed, clicked and captured. Keep script changes under a review and version control process. Decide what screenshots capture on each step, mask or avoid pages that show personal data, and confirm with the data owner whether captured images are permitted to be stored at all.
Screenshots, failures and what to alert on
Screenshots help triage failed browser items because the image shows the page the browser reached when a step broke. A failed login may show a rejected credential message or an unexpected interstitial page, and that picture often narrows the cause faster than a step name alone. The same images can also capture personal or session data, so decide retention, storage location and access before you enable them on a login journey. Confirm in the documentation for your Zabbix version how screenshots are captured and stored, and whether access to them can be restricted separately from host permissions. Use dedicated test accounts for the journey, never production customer credentials.
Separate journeys that fail outright from journeys that are only slow, because they route to different people. A failure such as a missing element, a changed button label or a rejected login usually points to a broken application, expired test credentials or a changed page, so it goes to the owning application team and the on-call rota that handles production incidents. A slow journey means every step completed but one exceeded its threshold. That often reflects load, a slow dependency or a poller or browser endpoint short of capacity, so it should reach the platform or performance owner first. Check poller sizing and the Selenium or ChromeDriver endpoint before paging the application team. Build separate triggers with different severities, and route them to different user groups through Zabbix actions.
Alert on sustained failure rather than on single runs. A browser test is exposed to transient network problems, a busy browser endpoint or an occasional slow page load, so one failed run is weak evidence that a journey is broken. Write trigger logic that evaluates several consecutive results or a short window of results. Agree the exact count with the team that owns the journey, based on how often the test runs and how much noise that team can absorb. Keep recovery notifications enabled so the on-call person knows when the journey is healthy again. Record the chosen logic next to the journey definition so that later changes to the test do not silently change alert behavior.
Test the alert path during the pilot, before the journey runs against production. Set a test account password to a wrong value, point a step at an element that does not exist in a staging copy, and add a controlled delay to a page so the slow-step trigger fires. Confirm that each case reaches the intended group through the intended media type. Check that the message names the journey and the failing step, includes a link to the screenshot, and that the recipient can open that screenshot with their own access level. Record every misrouted or unclear message and fix it before go-live. Also confirm that notifications still arrive outside business hours and when the server or a proxy is unavailable.
Limits and what to confirm in your environment
Browser items depend on several moving parts that you need to verify yourself, including the Zabbix release, the WebDriver endpoint, the identity provider and the data your checks capture. Confirm each one in your own environment before you move journey monitoring into production. The cards below cover the items that most often change the outcome.
Experimental status in your version
The topic brief flags browser items as experimental. Confirm the status of browser items in the exact Zabbix version you plan to run, read that version's release notes and documentation, and ask Zabbix whether the status affects production use. Record the answer in your change record, because a feature label can change between releases and an upgrade may change the answer with it.
WebDriver and browser version pairing
Browser items drive a Selenium or ChromeDriver endpoint, so the browser, driver and Zabbix versions must work together. Confirm which WebDriver and browser versions your Zabbix release supports, then pin both in your endpoint image so an automatic browser update does not break a login check overnight. Test each browser upgrade against a staging copy of your critical journeys first.
Session count per endpoint
Each browser check opens a session on the WebDriver endpoint, and concurrent checks compete for memory and CPU on that host. Ask Zabbix and your endpoint vendor for the practical session ceiling per endpoint and per browser type. Then size the poller count, check interval and endpoint pool against that ceiling, and load test with your real journey count before go-live.
SSO redirects and MFA prompts
Login journeys that pass through an identity provider send the browser to another domain, and an MFA challenge may require a second factor that a script cannot answer. Zabbix supports SAML and MFA for its own user logins, but that does not show how a monitored application's SSO behaves under automation. Use a dedicated test account, confirm whether your identity provider can exempt it from MFA, and verify that redirects and session cookies survive each step.
Support window for your LTS line
Browser items run inside the Zabbix release you choose, so its support window sets how long this design can stay unchanged. Zabbix 7.0 LTS has full support until 30 June 2027 and limited support until 30 June 2029. Zabbix 8.0 LTS is planned for Q4 2026. Compare these dates with your change calendar, and ask Zabbix how the browser item status and the planned 8.0 release apply to a 7.0 deployment.
Screenshots and test credentials
Browser checks can store screenshots of pages that show account details or personal data, and the journey definition holds test credentials. Confirm where screenshots are kept, who can view them in the frontend, how long they persist, and how credentials are stored in Zabbix macros. Agree these rules with your data protection and security teams before the first journey runs.
Questions teams ask before building browser checks
What drives the cost of building Zabbix browser checks?
Four things drive most of the cost: the number of journeys, the complexity of authentication, where the browser endpoint runs, and how much security review and pilot time the client requires. Each journey is a separate script to design, parameterize, build and test, so the count multiplies effort. Single sign-on, one-time codes and certificate-based login add test design work. Hosting the Selenium or ChromeDriver endpoint in your own infrastructure adds platform setup, patching and capacity planning. Build work is one-time, while keeping scripts aligned with application changes recurs. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for journeys, authentication, endpoint hosting, review and pilot to be itemized separately.
How long does a first browser journey take to build?
It depends on the scope and the environment, so no fixed figure applies in advance. The first journey usually takes longer than later ones because the team must choose stable page selectors, agree on test data, confirm how the application behaves under automation and set timeouts. Stabilizing the journey means running it repeatedly, since intermittent failures from slow pages, consent banners, rate limits or session expiry often appear only over time. A staging environment that resembles production shortens this work. Ask for the first-journey milestones and the criteria for calling a journey stable to be written into the scope, so both sides agree on what done means.
What does my team need to provide for browser monitoring?
Plan for test accounts, a suitable environment, time with the application team and a decision on screenshots. Test accounts should carry the same roles and sign-in path as real users, with multi-factor handling agreed in advance. A staging environment lets the team change scripts without triggering production alerts. The application team answers questions about page flows, planned changes and error messages. Screenshot retention needs an owner: screenshots of login pages or account views can contain personal or sensitive data, so decide whether to keep them, for how long, and who in Zabbix can view them. Also confirm the network path from the Zabbix server or proxy to the endpoint and to the application.
Can an internal team build Zabbix browser checks without a partner?
Yes, an internal team can build and run browser checks alone if it already operates Zabbix and has browser automation skills. The work needs someone comfortable with Zabbix items, triggers and proxies, plus someone who can write and debug Selenium or ChromeDriver scripts and operate the browser endpoint. Teams that have both skills often find the harder part is keeping checks reliable as the application changes. A partner can help with a fixed-scope build, review of authentication handling, hardening and documentation, then hand over runbooks. Internal teams should still plan review time, because monitoring that signs into production applications carries its own risks.
Does the experimental status of browser items affect the decision?
Use the experimental status to shape the pilot, not to skip the evaluation. Confirm in the Zabbix documentation for your exact version what the experimental label covers and how the feature is expected to change. In practice, expect to retest scripts after each Zabbix upgrade, keep a simpler fallback such as HTTP agent checks for basic availability, and run browser checks alongside existing monitoring for a period before they drive on-call paging. Ask your Zabbix support provider whether the feature falls within your support tier. Document the exit criteria, so the team knows when a check moves from pilot to production alerting.
Which Zabbix version should I choose for browser checks?
Choose the version that matches your support and upgrade cycle, then confirm browser item status in that version's documentation. Zabbix 7.0 LTS was released on 4 June 2024, with full support until 30 June 2027 and limited support until 30 June 2029. Zabbix 7.4 was released on 1 July 2025 and receives full support until Zabbix 8.0 LTS. Zabbix 8.0 LTS is planned for Q4 2026. LTS releases are generally the better fit for production monitoring because they receive longer support. Check whether browser item behavior, parameters and the experimental label differ between your chosen version and the version you plan to move to, and schedule an upgrade test before committing.
How do poller sizing and timeouts affect browser check reliability?
Browser checks are heavier than simple HTTP checks because each run starts a browser session, loads pages, runs scripts and may capture screenshots. Undersized pollers cause queued checks and late results, which can look like application outages. Timeouts must cover page load, sign-in and any waits for the application, but they should be short enough that a broken journey fails visibly. Set them from measured run times in staging, confirm them in production, and review them after application or Zabbix changes. Keep the browser endpoint close to the monitored application to reduce network delay, and watch endpoint memory and CPU, because too many parallel sessions can exhaust resources before Zabbix reports a clear problem.
Should screenshots be kept, and who should see them?
Decide this before the first journey runs, because screenshots are the most likely place for personal or sensitive data to appear. Screenshots taken during sign-in or on account pages can show names, account identifiers or balances. Set a retention period that matches your data protection policy, and confirm whether it applies to the Zabbix database, the endpoint's local storage and any exported history. Limit viewing to the Zabbix roles that need it for troubleshooting, and check who can read screenshots through the frontend and API. If the answer is no screenshots, the team still needs error logs and step-level results to diagnose failures.
How DeployOpen scopes and delivers browser monitoring
DeployOpen scopes browser monitoring as its own engineering task, covering which login flows and user journeys matter, where the Selenium or ChromeDriver endpoint runs, and how the poller is sized. We build it in your infrastructure, document it and hand it over, with the experimental status of browser items stated plainly for your team.
How we scope
- Written scope listing each login flow and user journey to monitor, with the pass and fail criteria for each
- Agreed target hosts, the Selenium or ChromeDriver endpoint location, and the Zabbix version your team runs
- Fixed-scope agreement in writing before work starts, with ongoing support available as a retainer
How we build
- Browser item configuration for each journey, with poller capacity sized to the number of concurrent checks
- Timeouts, step-level error handling and screenshot capture settings tuned against the applications being tested
- Test accounts and credentials kept in your secret store, never hard-coded into item definitions
How we hand over
- Runbook covering item layout, proxy placement, poller settings, and what each failure looks like in alerts
- Documented experimental status of browser items for your Zabbix version, with the risks your team accepts
- Walkthrough with operators so they can add a journey, adjust a timeout and read a failed screenshot
How we support
- Optional retainer covering Zabbix upgrades, with browser checks retested in staging before each rollout
- Review of journey changes after application releases, since login pages and workflows often change
- Capacity review when the number of journeys or check frequency grows, using your observed poller load
