File Server & Monitoring

This chapter covers four independent features that share a menu group in the navigation. They are not part of Collections, and they are not tied to Policies. Each feature stands alone and is documented in its own section.

• File Server is a centralised storage hub for binaries, scripts, packages, and any other file you want agents or technicians to pull from a single known location.
• Relay Server lets you reach a device's TCP service (Remote Desktop, SSH, a web admin UI, a database port) through a relay tunnel when a direct connection to the device is not possible.
• Website Uptime Monitoring checks external URLs from the server on a schedule and raises events when availability, performance, SSL certificates, content, or DNS falls outside thresholds.
• Port Scanner sweeps a manually-curated list of targets for open TCP ports and surfaces findings against an allowlist.

9.1 File Server

Manage Files at /manage_files is the product's file distribution hub. Use it to publish anything your agents, scripts, or technicians need to download from a predictable place — installers, configuration bundles, intermediate artefacts a script produces on one device and another consumes, or simple documentation you want a tray-icon-initiated URL to resolve to.

List columns

The file list shows eight columns:

Upload, download, and delete

Uploads go through the Upload File action in the page toolbar. The action opens the native file picker, then streams the selected file to the File Server with a progress indicator. A single upload can carry up to 10 GB. Larger artefacts must be split before upload.

Downloads are initiated from a file's context menu. The resulting URL embeds the file's GUID, and, for private files, its Password. Public files do not require a password in the URL.

Delete is also on the context menu. Deleting a folder removes its contents; there is no separate recursive-delete confirmation beyond the standard delete prompt.

Public versus private access

Every file has one of two access levels, toggled inline in the Access column:

• Public — any holder of the download URL can retrieve the file. No password in the URL.
• Private — the download URL must include the file's Password. Without it, the server rejects the request.

Access is file-by-file. There is no directory-level ACL and no per-user ACL — any user who can reach the page can change a file's access level.

The /netlock folder

A folder named /netlock at the root is gated by a dedicated permission, file_server_netlock. Users without that permission see an empty view when they open it and cannot upload into it. Treat /netlock as the place for files you want kept out of the hands of technicians who otherwise have File Server access.

SHA512 integrity

Every file shows its SHA512 hash in the list. When a script or an agent downloads the file, you can compare that value to the hash of the received bytes to confirm the content arrived intact and was not modified in transit. The hash is computed by the server on upload and does not change unless the file is replaced.

Typical uses

The File Server is built for two audiences.

• Agents and scripts. A PowerShell or Bash script on a device fetches a file by its download URL, checks the returned hash against the published SHA512, then acts on the content. This is the standard way to distribute a large binary that would be awkward to embed in a script.
• Technicians. A private URL with a password lets you hand a customer one link to an installer or log bundle without giving them access to the rest of the File Server.

Dialogs

• Create Directory — enter a folder name to create a subdirectory in the currently open path.
• Rename — rename the selected file or folder.

There is no dedicated "Add File" dialog; the native file picker handles uploads.

Permissions

9.2 Relay Server

The Relay Server at /relay_server is the console-side view of persistent and temporary relay tunnels. A relay session proxies a single TCP port from a target device out to a connection endpoint your workstation can reach, so you can open a Remote Desktop, SSH, web admin, or database session against a device that is not directly reachable on your network.

How a relay session works

A session has three parties. The device runs the Relay App, which registers with the Remote Server and stands ready to proxy traffic. The Remote Server holds the session definition and accepts connections from your workstation on the configured relay address. Your workstation opens a TCP connection to that relay address, which the Relay App forwards to the Remote Server, which forwards it to the chosen agent, which forwards the connection to the chosen port on the device.

Everything in the tunnel is a single TCP stream. There is no UDP relaying, no multi-port session, and no protocol interpretation — the relay does not care whether the bytes are SSH, RDP, HTTP, or something else.

Persistent versus temporary sessions

Every session is either persistent or temporary:

• Persistent sessions are stored in the server's database. They survive a server restart and can be re-enabled long after they were first configured. Use persistent sessions for sites or services you expect to connect to repeatedly.
• Temporary sessions live only in server memory. They are gone as soon as the session is closed or the server is restarted. Use temporary sessions for one-off troubleshooting where the session definition is not worth keeping.

A persistent session can be toggled on or off from the list; a disabled persistent session keeps its definition but refuses new connections until you re-enable it.

Lifecycle states

A session's Status column shows one of:

• Active — a client is currently connected and bytes are flowing.
• Ready to connect — the session is registered and waiting for a client.
• Device offline — the target device's Relay App is not currently registered, so the session cannot complete.
• Disconnecting — the session is in the process of tearing down.
• Disabled — a persistent session that has been turned off via the toggle.
• Inactive — the session exists but has no registered Relay App.

List columns

The list shows:

• Device — device name, with the owning tenant name beneath.
• Target Port — the port on the device being proxied.
• Protocol — TCP.
• Status — one of the lifecycle states above.
• Connections — current count of connected clients.
• Persistent — Yes for stored sessions; blank or a Temp indicator for in-memory sessions.
• Enabled — toggle, shown on persistent sessions only.
• Actions — per-row controls.

Per-session actions

The Actions column exposes three controls:

• Copy Connection String — copies the relay address to the clipboard so you can paste it into your RDP client, SSH client, or browser.
• Enable / Disable — toggles a persistent session on or off. Not shown on temporary sessions.
• Close / Delete — closes the session and removes it from the relay server. For persistent sessions this also removes the stored definition.

How the Relay App registers

There is no discovery flow in the console. The Relay App on the device authenticates to the Remote Server using an API key and registers the sessions it is willing to serve. From that point the console can list those sessions and manage their lifecycle. Two account-area dialogs expose the API-key side of the integration:

• The Relay Identities Overview lists the API keys associated with the current admin.
• The Relay Account dialog holds the relay account settings for the current admin.

Both live in the account menu, not on the Relay Server page itself.

Create a relay session

The Create Relay Session dialog is the primary affordance for starting a new session.

Fields, in order:

• Tenant — scopes the device picker.
• Location — scopes further within the tenant.
• Group — optional; scopes further within the location.
• Device — an autocomplete picker populated by the scope above.
• Port — a dropdown pre-populated with the common services used through relays: RDP, SSH, HTTP, HTTPS, VNC, MySQL, PostgreSQL, and others. Pick a preset or type a port number directly.
• Protocol — TCP. No other protocols are currently supported.
• Description — free text for your own reference.

Submitting the dialog registers the session with the Remote Server. If the target device's Relay App is online, the session becomes Ready to connect immediately; otherwise it waits in Device offline until the Relay App registers.

Tip: For long-lived sessions you will reconnect to, enable the Persistent flag (on the list once created) rather than re-creating a temporary session each time. Persistent sessions keep their relay address across restarts.

Permissions

9.3 Website Uptime Monitoring

Website Uptime Monitoring at /website-uptime-monitoring watches external URLs from the server side. The server fires HTTP requests at each configured target on an interval, evaluates the response against a set of rules, and raises events when thresholds are breached. This is the right feature for public-facing sites, customer portals, and any HTTP endpoint where you care about availability or performance as seen from outside the device fleet.

Architecture

Checks run on the server. No agent is involved, which means a monitor sees the target from the network the server sits on — not from inside any particular customer's LAN. This matches how an external customer would reach the site, which is usually what you want for public endpoints. For internal-only URLs, consider a device-side sensor instead (see Chapter 8.3).

The three tabs

The page has three tabs, selected across the top:

• Monitors — the list of configured targets, their current status, and the affordances for add / edit / delete.
• Details — historical timeline for a selected monitor: response time, SSL certificate, DNS lookup, and content-check results over the chosen window.
• Incidents — the chronological list of raised incidents across all monitors, with start time, duration, and the reason that triggered the incident.

What a monitor checks

Each monitor performs a single HTTP request per interval and evaluates the response on multiple axes:

• HTTP status. A target has an Expected Status Code (default 200). Anything else is a failure.
• SSL certificate. If SSL monitoring is enabled, the monitor inspects the certificate chain for valid-from and valid-to dates, the issuer, subject, and thumbprint. Expiry raises a warning at the configurable warning-threshold days and critical at the critical-threshold days.
• Response time. The monitor records round-trip time and time-to-first-byte in milliseconds. A configurable threshold raises a Degraded status when exceeded.
• DNS resolution. If DNS monitoring is enabled, the monitor records lookup time and the resolved A, AAAA, and MX records.
• Content presence. With content monitoring enabled, the monitor checks the response body for a configured Keyword and for a configured CSS Selector. Either missing raises a content error.
• Defacement detection. When enabled, the monitor stores a SHA hash of the response content and alerts when the hash changes unexpectedly.

The outcome of each check is written to the monitor's history and, where thresholds are breached, produces an event under the Uptime Monitoring type (see Chapter 12.2).

List columns (Monitors tab)

• Status — one of Up, Down, Degraded, Timeout, SSL Error, DNS Error, Content Error, Pending.
• Name — the monitor's label.
• URL — the target, truncated to fit the column.
• Interval — the check cadence, formatted (for example 5m).
• Last Check — timestamp of the most recent check.
• Failures — running count of consecutive failures.
• Tenant — the tenant the monitor belongs to.
• Actions — edit / delete controls.

Creating a monitor

The monitor dialog is organised into eight sections:

• General — Tenant, Name, URL, Enabled.
• HTTP Settings — HTTP Method (GET, POST, HEAD, PUT) and Expected Status Code.
• Intervals & Timeouts — Check Interval (default 300 s, range 30 to 86400 s), Timeout (default 30 s, range 1 to 120 s), and Retry Count (default 3, range 1 to 10).
• Redirects — Follow Redirects and Max Redirects (default 5).
• SSL Monitoring — enable, warning threshold days (default 30), critical threshold days (default 7).
• Content Monitoring — enable, Keyword, CSS Selector, and the Defacement Detection hash toggle.
• DNS Monitoring — enable.
• Performance Thresholds — Response Time Alert (default 2000 ms), Load Time Alert (default 5000 ms), and SLA Target (default 99.90%).
• Notifications — per-channel checkboxes for Email, Microsoft Teams, Telegram, ntfy.sh, and Webhook. Each channel must be configured in Settings → Notifications first.

The same dialog covers add and edit; the title changes based on which action opened it.

Incidents

The Incidents tab collates the consolidated timeline of raised incidents. An incident starts when the first failing check crosses its threshold and closes when the target recovers. Each row shows the triggering reason (for example Down, SSL Error, Degraded), the monitor, the duration, and the recovery time.

Permissions

There are no granular add / edit / delete flags — access is all-or-nothing at the page level, with tenant scoping applied through the standard tenant-list permission.

9.4 Port Scanner

Port Scanner at /port-scanner sweeps a manually-configured list of targets for open TCP ports and tracks the findings against an allowlist. Use it to catch drift on internet-facing hosts — a newly opened port that shouldn't be open, a forgotten staging service exposed to the internet, or an unexpected change to a web server's Server banner.

Compliance scope — targets only

The Port Scanner scans only manually-configured custom targets. It does not enumerate the devices in your fleet and scan their external IPs. This behaviour is intentional and enforced: the Settings tab states that automatic scanning of device external IPs has been disabled for compliance reasons. If you want a host scanned, you must add it yourself as an explicit target.

The five tabs

The page has five tabs across the top:

• Scan Results — the findings table, one row per discovered open port per scan.
• Custom Targets — the targets the scanner sweeps, one host per row.
• Whitelist — the allowlist of host+port pairs that should be treated as expected rather than as a finding.
• Ports — the catalogue of port numbers the scanner will test on each target.
• Settings — global scanner configuration.

Custom Targets

Targets are added one at a time from the Custom Targets tab. Each target has a Tenant, Name, Host (hostname or IP address), and Description, plus an enabled/disabled toggle. The scanner only sweeps enabled targets.

Ports catalogue

The set of ports tested is global — not per-target. The Ports tab lets you add a port (1–65535), give it a Name (the service label shown against findings), and a Details field for notes. Each port can be enabled or disabled. A disabled port is skipped during scans but kept in the catalogue for later.

This design assumes you care about the same port numbers everywhere. If you need a different port set for a particular target, the current implementation is to maintain a single unified catalogue and filter findings by the target column of the results view.

Whitelist

The Whitelist tab is the allowlist. A whitelist entry has Tenant, Name, Host (or * for any host), Port (or 0 for any port), and Description. A finding that matches a whitelist entry is treated as expected and is not surfaced as a concern on the Scan Results tab.

Use * host plus a specific port for "this port is always OK to be open anywhere", and a specific host plus 0 for "any port being open on this host is OK".

Settings

Global scanner configuration:

• Protocols — TCP only. UDP scanning is not implemented.
• TCP timeout — milliseconds per port probe, default 3000, range 500 to 30000.
• Scan interval — hours between automatic scans, default 24, range 1 to 720.
• Max concurrent scans — maximum parallel port probes, default 50, range 1 to 500.
• Auto-cleanup — retention in days for old results, default 90.

A Trigger Scan Now button on the Settings tab runs an on-demand scan outside the interval.

Scan Results columns

• Host — the target host.
• Port — the discovered open port.
• Service — the service label from the Ports catalogue entry for that port.
• Target — the device name if the host maps to a known device; otherwise blank.
• Banner — the first bytes returned by the service, where available.
• Title (HTTP) — the <title> element of the HTTP response, if served.
• Title (HTTPS) — the <title> element of the HTTPS response, if served.
• Scan Date — the timestamp of the scan that produced this row.
• Actions — per-row controls, including opening the result details dialog.

Dialogs

• Add / Edit Custom Target — Tenant, Name, Host, Description.
• Add Whitelist Entry — Tenant, Name, Host, Port, Description.
• Add / Edit Port — Port Number, Name, Details.
• Scan Result Details — read-only display of host, port, service, banner, titles, and scan date for a single finding.

Permissions

Tenant scoping on the Custom Targets, Whitelist, and Scan Results tabs is enforced through the standard tenant-list permission.

Permissions

The File Server, Relay Server, Website Uptime Monitoring, and Port Scanner each have their own flags. The complete list for this chapter:

See Appendix X.2 for the full permission catalogue.

Related chapters

• Chapter 8 — Collections covers device-side sensors, which are the right choice for monitoring URLs or ports from inside a customer network.
• Chapter 12 — Events & Audit documents how Website Uptime and Port Scanner events appear in the Events view.
• Chapter 3 — Devices describes remote control, which complements the Relay Server for interactive sessions.
• Appendix X.5 — Integration endpoints lists the notification endpoints that uptime monitors and port scanner results can reach.