defmodule ToweropsWeb.HelpLive.Index do @moduledoc false use ToweropsWeb, :live_view alias Towerops.Accounts alias Towerops.Accounts.Scope alias Towerops.HTTP alias Towerops.Organizations @impl true def mount(_params, session, socket) do # Check if user is logged in via session current_user = get_current_user(socket, session) is_authenticated = !is_nil(current_user) # Load user's default organization if authenticated current_organization = if current_user do case Organizations.list_user_organizations(current_user.id) do [first_org | _] -> first_org [] -> nil end end # Build current_scope if authenticated current_scope = if current_user do current_user |> Scope.for_user() |> Scope.put_organization(current_organization) end socket = socket |> assign(:page_title, t("Help")) |> assign(:current_user, current_user) |> assign(:is_authenticated, is_authenticated) |> assign(:current_scope, current_scope) |> assign(:timezone, if(current_user, do: current_user.timezone, else: "UTC")) |> assign(:generated_password, nil) |> assign(:password_generating, false) # Generate initial password if connected?(socket) do send(self(), :fetch_random_password) end {:ok, socket} end @impl true def handle_params(params, _url, socket) do section = Map.get(params, "section", "about") socket = socket |> assign(:active_section, section) |> assign(:generated_password, nil) |> assign(:password_generating, false) {:noreply, socket} end @impl true def handle_event("generate_password", _params, socket) do socket = assign(socket, :password_generating, true) send(self(), :fetch_random_password) {:noreply, socket} end @impl true def handle_info(:fetch_random_password, socket) do case generate_random_password() do {:ok, password} -> {:noreply, socket |> assign(:generated_password, password) |> assign(:password_generating, false)} {:error, reason} -> {:noreply, socket |> assign(:password_generating, false) |> put_flash(:error, t("Failed to generate password: %{reason}", reason: reason))} end end defp generate_random_password do # Generate a 24-character truly random password from random.org # Format: uppercase, lowercase, and digits url = "https://www.random.org/strings/?num=1&len=24&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new" case HTTP.get(__MODULE__, url) do {:ok, %{status: 200, body: body}} -> password = String.trim(body) {:ok, password} {:ok, %{status: status}} -> {:error, "random.org returned status #{status}"} {:error, error} -> {:error, format_request_error(error)} end end defp format_request_error(%_{} = error), do: Exception.message(error) defp format_request_error(error), do: inspect(error) defp get_current_user(socket, session) do # Try to get current_user from socket assigns (if already set by on_mount) with nil <- Map.get(socket.assigns, :current_user), token when not is_nil(token) <- session["user_token"], {user, _authenticated_at} <- Accounts.get_user_by_session_token(token) do user else %Towerops.Accounts.User{} = user -> user _ -> nil end end slot :inner_block, required: true defp code(assigns) do ~H""" {render_slot(@inner_block)} """ end attr :active_section, :string, required: true attr :generated_password, :string, default: nil attr :password_generating, :boolean, default: false defp help_content(assigns) do ~H"""

Help & Documentation

Learn how to use Towerops to monitor your network infrastructure

<%= case @active_section do %> <% "about" -> %>

About Towerops

Towerops is a modern network monitoring and management platform designed to provide comprehensive visibility into your network infrastructure. It came out of a need to simplify network monitoring and alerting while running a wireless ISP.

Our promise to you:

  • No random marketing emails or sign up for our newsletter popups.
  • No trackers EVER, no external libraries used.
  • No ads or sponsored content.
  • No data collection or sharing.
  • Our remote agent is fully open source and ONLY collects monitoring jobs from the server and WILL NEVER allow us to access any part of your internal network.

Think of Towerops as combining the best of LibreNMS, Icinga2/Nagios, and PagerDuty into a single, unified platform. You get deep network device monitoring with SNMP auto-discovery, flexible health checks and alerting, and intelligent incident management—all with a modern interface that makes complex monitoring workflows simple and accessible.

Towerops is not and has no plans to be a replacement for a full WISP/network billing system.

Network Monitoring

Like LibreNMS, discover and monitor network devices via SNMP with support for multi-vendor equipment, interface statistics, and topology mapping.

Health Checks & Alerting

Like Icinga2/Nagios, configure flexible monitoring checks with customizable thresholds and alert conditions for any metric or device state.

Incident Management

Like PagerDuty, manage incidents with intelligent alerting, escalation policies, and notification routing to keep your team informed.

<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Ready to get started? Check out the <.link patch={~p"/help?section=getting-started"} class="underline hover:text-blue-900 dark:hover:text-blue-200" > Getting Started guide to begin monitoring your network infrastructure.

<% "getting-started" -> %>

Getting Started with Towerops

Towerops is a network monitoring platform that helps you keep track of your network devices, monitor their health, and get alerts when issues occur.

Quick Start Guide

1

Create a Site (Optional)

Sites represent physical or logical locations where your network devices are located. If you manage multiple locations, start by creating a site for your office, data center, or any location where you have equipment.

Navigate to <.code>Sites → <.code>Add Site

Sites are disabled by default and can be enabled later in <.link patch={~p"/help?section=settings"} class="underline hover:text-gray-700 dark:hover:text-gray-300" > Organization Settings → General tab.

2

Add Your First Device

Add network devices like routers, switches, access points, or servers. You'll need the device's IP address or hostname, and SNMP community string (for SNMP-enabled devices).

Navigate to <.code>Devices → <.code>Add Device

3

View Device Metrics

Click on any device to view real-time metrics including CPU usage, memory, temperature, interface traffic, and more. Explore the different tabs to see network topology, port status, and historical performance data.

<.icon name="hero-light-bulb" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Pro Tip

For devices behind firewalls or in remote locations, you can deploy a remote poller to monitor devices locally without exposing them to the internet. See the <.link patch={~p"/help?section=agents"} class="underline hover:text-blue-900 dark:hover:text-blue-200" > Remote Pollers section for more information.

<% "sites" -> %>

Sites

Sites are an optional organizational feature that lets you group devices by physical or logical locations such as offices, datacenters, customer locations, or network zones. Sites are disabled by default to keep things simple for single-location deployments.

When to Enable Sites

Consider enabling sites if you:

  • Manage multiple physical locations - Offices, datacenters, retail stores, etc.
  • Want to group credentials by location - Different SNMP communities or credentials per site
  • Need location-based monitoring - Assign different remote pollers to different sites
  • Organize by customer or department - Logical groupings for multi-tenant or large networks

When to Skip Sites

You can skip enabling sites if you:

  • Have a single location - All devices in one office or datacenter
  • Want a simpler setup - Devices belong directly to your organization without extra grouping
  • Don't need location-based credentials - Organization-level credentials work for all devices
<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Note

Sites are optional and disabled by default. You can start without sites and enable them later if your needs change. When sites are disabled, all devices belong directly to your organization.

How Sites Work

When sites are enabled, devices can be organized into sites, and credentials (SNMP communities, usernames, passwords) can be set at three levels:

1. Organization Level

Default credentials that apply to all devices across all sites in your organization.

2. Site Level (when sites enabled)

Override organization defaults for all devices at a specific site. Useful when different locations have different network configurations.

3. Device Level

Override organization or site credentials for a specific device. Useful for devices with unique configurations.

Enabling Sites

1

Navigate to Organization Settings

Go to <.code>Settings → <.code>Organization and scroll to the "Site Organization" section.

2

Enable the "Use Sites" Toggle

Check the box for "Use sites to organize devices" and save your settings.

3

Create Your First Site

Navigate to <.code>Sites → <.code>Add Site to create your first site. Give it a descriptive name like "Main Office" or "Dallas Datacenter".

4

Assign Devices to Sites

When creating or editing devices, you can now assign them to specific sites. The site selector will appear in the device form.

<.icon name="hero-exclamation-triangle" class="h-5 w-5 text-yellow-600 dark:text-yellow-400 flex-shrink-0 mt-0.5" />

Disabling Sites

If you disable sites after enabling them, all devices will be removed from their sites and assigned directly to the organization. Site assignments will be lost, but devices will remain in your organization and continue to be monitored.

<% "cloud-pollers" -> %>

Cloud Pollers

If you have publicly reachable devices, they will be automatically polled from one of our cloud pollers unless overridden by your settings. Our cloud infrastructure monitors your devices without requiring any additional setup or agent installation.

Active Cloud Pollers

Location IPv4 Address IPv6 Address
DFW (Dallas-Fort Worth) 144.202.64.79 2001:19f0:6401:0af2:5400:05ff:fee7:1bfb
<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Firewall Configuration

If your devices are behind a firewall, make sure to allow SNMP traffic (UDP port 161) and ICMP (for ping monitoring) from these IP addresses. For devices not accessible from the public internet, consider using a <.link patch={~p"/help?section=agents"} class="underline hover:text-blue-900 dark:hover:text-blue-200" > Remote Poller instead.

<% "agents" -> %>

Remote Pollers

Remote pollers are lightweight Docker containers that run on your network to monitor devices that aren't accessible from the public internet — behind firewalls, on private networks, or at remote locations. They use minimal resources (1 CPU core, 512 MB RAM) and auto-update themselves via Watchtower. Just deploy a <.code>docker-compose.yml and you're done.

Requirements

Remote pollers can run on any system that supports Docker Compose, including:

  • Linux servers (Ubuntu, Debian, CentOS, RHEL, etc.)
  • Windows Server with Docker Desktop
  • macOS with Docker Desktop
  • Raspberry Pi or other ARM-based systems
  • Virtual machines (VMware, Hyper-V, Proxmox, etc.)

Minimum requirements: 1 CPU core, 512 MB RAM, and network access to your devices

Getting Started

1

Create an Agent Token

Navigate to the <.code>Agents page in Towerops and create a new agent token. This token authenticates your remote poller with the Towerops platform.

2

Create a docker-compose.yml

When you create a new agent on the <.code>Agents page, Towerops will show you a ready-to-use <.code>docker-compose.yml with your agent token pre-filled. It looks like this: 

<%= raw(~S[services:
    towerops-agent:
    image: ghcr.io/towerops-app/towerops-agent:latest
    container_name: towerops-agent
    restart: unless-stopped
    environment:
      - TOWEROPS_API_URL=https://app.towerops.net/
      - TOWEROPS_AGENT_TOKEN=your-token-here
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
      - "com.centurylinklabs.watchtower.scope=towerops"

    watchtower:
    image: containrrr/watchtower:latest
    container_name: towerops-watchtower
    restart: unless-stopped
    environment:
      - WATCHTOWER_POLL_INTERVAL=43200
      - WATCHTOWER_LABEL_ENABLE=true
      - WATCHTOWER_SCOPE=towerops
      - WATCHTOWER_CLEANUP=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock]) %>

The agent is lightweight — it uses minimal CPU and memory. Watchtower is included to automatically update the agent every 12 hours, so you never have to think about it.

3

Deploy It

Copy the <.code>docker-compose.yml to your server and run: 

docker compose up -d

That's it. The agent will connect to Towerops within seconds and start polling your local devices. You'll see it come online on the Agents page.

4

Assign Devices to Remote Poller

You can assign devices to your remote poller in several ways:

  • Per Organization: Set a default agent for all devices in your organization
  • Per Site: Set a default agent for all devices at a specific site
  • Per Device: Select the remote poller when creating or editing individual devices

Devices assigned to a remote poller will be monitored from your local network instead of from the cloud.

<.icon name="hero-shield-check" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Security Note

Remote pollers use secure WebSocket connections to communicate with Towerops. Your agent token is encrypted and should be kept confidential. The remote poller only needs outbound HTTPS access (port 443) to connect to Towerops - no inbound ports need to be opened on your firewall.

Managing Remote Pollers

You can view the status of your remote pollers on the Agents page. The page shows:

  • Last connection time
  • Number of devices assigned to each poller
  • Connection status (online/offline)
<.icon name="hero-exclamation-triangle" class="h-5 w-5 text-yellow-600 dark:text-yellow-400 flex-shrink-0 mt-0.5" />

Important

If a remote poller goes offline, devices assigned to it will not be monitored until the poller comes back online. Consider setting up monitoring alerts for your remote pollers to be notified if they disconnect.

<% "graphs" -> %>

Graphs & Live Polling

Towerops provides powerful visualization capabilities for all monitored metrics. Every sensor, interface, and metric can be viewed as a time-series graph with multiple time ranges and a real-time live polling mode for instant feedback.

Accessing Graphs

Graphs are available throughout Towerops wherever metrics are displayed:

  • Device Overview: Click any metric tile (CPU, Memory, Temperature, etc.) to view its graph
  • Sensors Tab: Click the graph icon next to any sensor reading
  • Interfaces Tab: Click the graph icon next to any interface to view traffic graphs
  • Storage Tab: Click any storage volume to view usage over time

Time Ranges

All graphs support multiple time ranges for analyzing trends at different scales:

1 Hour

Recent activity with high detail

6 Hours

Half-day trends and patterns

12 Hours

Business day overview

24 Hours (Default)

Full day of activity

7 Days

Weekly trends and patterns

30 Days

Monthly overview and capacity planning

Live Polling Mode

Live mode provides real-time sensor monitoring with data updating every second. This is perfect for:

  • Testing configuration changes and seeing immediate effects
  • Monitoring system load during maintenance or upgrades
  • Watching temperature changes during thermal testing
  • Observing traffic patterns during load testing
  • Real-time troubleshooting of performance issues
<.icon name="hero-signal" class="h-5 w-5 text-green-600 dark:text-green-400 flex-shrink-0 mt-0.5" />

How Live Mode Works

  • Polls sensors directly via SNMP every 1 second
  • Displays a rolling 5-minute window (300 data points)
  • Updates chart in real-time as new data arrives
  • Automatically stops when you switch to another time range
  • Works with remote pollers - polling happens on the agent

Using Live Mode

1

Open Any Graph

Navigate to any device and click on a metric graph (CPU, Memory, Temperature, Traffic, etc.)

2

Click the "Live" Button

The Live button has a distinctive green gradient style and will pulse when active

3

Watch Real-Time Updates

The graph will start updating every second with fresh data. A pulsing green indicator shows that live polling is active.

4

Switch Back to Historical Data

Click any other time range button to stop live polling and view historical data

Supported Metrics in Live Mode

<.icon name="hero-cpu-chip" class="h-4 w-4 text-blue-500" /> CPU / Processors

Real-time CPU load and utilization

<.icon name="hero-circle-stack" class="h-4 w-4 text-blue-500" /> Memory Usage

RAM utilization percentage

<.icon name="hero-fire" class="h-4 w-4 text-orange-500" /> Temperature

Device and component temperatures

<.icon name="hero-bolt" class="h-4 w-4 text-yellow-500" /> Voltage

Power supply voltages

<.icon name="hero-server-stack" class="h-4 w-4 text-purple-500" /> Storage

Disk usage and capacity

<.icon name="hero-hashtag" class="h-4 w-4 text-green-500" /> Custom Metrics

Sessions, connections, and counts

<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Note About Traffic Graphs

Live mode is currently only available for sensor metrics (CPU, memory, temperature, etc.). Interface traffic graphs use historical data only, as traffic calculations require comparing multiple SNMP polls over time.

Tips for Using Graphs

Multiple Sensors on One Graph

When viewing aggregate metrics (like "Temperature" for all sensors), the graph automatically displays all sensors of that type with different colors for easy comparison.

Max and Min Values

Historical graphs (non-live) display the maximum and minimum values for the selected time range at the bottom of the chart for quick reference.

Traffic Graph Direction

Interface traffic graphs show outbound traffic as positive values (above zero) and inbound traffic as negative values (below zero) for easy visualization of bidirectional flow.

Automatic Unit Scaling

Traffic graphs automatically scale units (bps, Kbps, Mbps, Gbps) based on the data range for optimal readability. Hover over data points to see exact values.

<.icon name="hero-light-bulb" class="h-5 w-5 text-yellow-600 dark:text-yellow-400 flex-shrink-0 mt-0.5" />

Performance Tip

Live polling makes direct SNMP requests every second. While this provides instant feedback, keeping many live graphs open simultaneously may impact device performance. Use live mode for troubleshooting and testing, then switch back to historical ranges for routine monitoring.

<% "settings" -> %>

Organization Settings

Organization Settings is the central hub for configuring your Towerops organization. Access it from the main navigation under <.code>Organization Settings. The settings page uses a tabbed interface to organize different configuration areas.

General Tab

The General tab lets you manage basic organization properties:

  • Organization Name — The display name for your organization
  • Default Organization — Set this as the default org when logging in
  • Sites Toggle — Enable or disable site-based device organization (see the <.link patch={~p"/help?section=sites"} class="underline hover:text-blue-900 dark:hover:text-blue-200 text-blue-700 dark:text-blue-300" > Sites section for details)

SNMP Tab

Configure organization-wide SNMP defaults used for device polling:

  • SNMP Version — Choose between v1, v2c, or v3
  • Community String — The SNMP community string for v1/v2c
  • SNMPv3 Credentials — Username, auth protocol, auth passphrase, privacy protocol, and privacy passphrase
  • Port — SNMP port (default: 161)
<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Credential Hierarchy

SNMP credentials follow a hierarchy: Device > Site > Organization. Device-level settings take the highest priority, followed by site-level, then organization-level defaults. This lets you set sensible defaults while overriding for specific locations or devices.

Use the Force Apply button to push the organization's SNMP settings to all devices, overriding any device or site-level customizations.

MikroTik Tab

Configure organization-wide SSH credentials for MikroTik device monitoring. This tab is only accessible to superusers. See the <.link patch={~p"/help?section=mikrotik"} class="underline hover:text-blue-900 dark:hover:text-blue-200 text-blue-700 dark:text-blue-300" > MikroTik section for detailed setup instructions.

Agents Tab

Manage remote poller (agent) assignments for your organization:

  • Default Agent — Set a default remote poller for all devices in the organization
  • Assignment Breakdown — View how devices are distributed across pollers (cloud vs. remote agents)

Use the Force Apply button to push the default agent assignment to all devices, overriding any device or site-level agent selections.

Integrations Tab

Connect Towerops with third-party services. See the <.link patch={~p"/help?section=integrations"} class="underline hover:text-blue-900 dark:hover:text-blue-200 text-blue-700 dark:text-blue-300" > Integrations section for full details on available integrations and how to configure them.

<% "integrations" -> %>

Integrations

Integrations allow you to connect Towerops with third-party services to enrich your monitoring data, sync subscriber information, and streamline your workflow. Configure integrations from <.code>Organization Settings → <.code>Integrations tab.

Preseem

Preseem is a Quality of Experience (QoE) monitoring platform designed for WISPs and broadband providers. The Preseem integration syncs subscriber and access point QoE data into Towerops, giving you a unified view of network health alongside device monitoring.

What It Syncs

  • Subscriber QoE scores and metrics
  • Access point performance data
  • Latency, jitter, and packet loss statistics

Configuration

1

Get Your Preseem API Key

Log in to your Preseem dashboard and generate an API key from your account settings.

2

Add the Integration

Navigate to <.code>Organization Settings → <.code>Integrations tab. Enter your Preseem API key and configure the sync interval.

3

Test the Connection

Use the Test Connection button to verify your API key is valid and Towerops can reach the Preseem API.

<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Sync Schedule

Preseem data is synced automatically on a periodic schedule based on your configured sync interval. You can also trigger a manual sync at any time from the integration settings.

Gaiia

Gaiia is a billing and subscriber management platform. The Gaiia integration syncs subscriber data, service plans, and entity mappings into Towerops, enabling you to correlate network issues with specific customers and services.

What It Syncs

  • Subscriber accounts and contact information
  • Service plans and subscription status
  • Entity mappings between Gaiia and Towerops devices

Configuration

1

Configure Gaiia Credentials

Navigate to <.code>Organization Settings → <.code>Integrations tab and enter your Gaiia API credentials.

2

Set Up Webhooks

Configure a webhook in your Gaiia account pointing to the webhook URL provided in the integration settings. Webhooks enable real-time updates when subscriber data changes in Gaiia.

3

Entity Mapping & Reconciliation

After the initial sync, review the entity mapping to ensure Gaiia subscribers are correctly matched to Towerops devices. Use the reconciliation tools to resolve any mismatches.

<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Sync Schedule

Gaiia data is synced through two mechanisms: automatic periodic syncs pull the full dataset on a schedule, while real-time webhooks push individual changes as they happen in Gaiia. This ensures your data stays current without excessive API calls.

PagerDuty

PagerDuty is an incident management and on-call alerting platform. The PagerDuty integration provides 2-way alert sync — when a device goes down in Towerops, a PagerDuty incident is automatically triggered. Acknowledging or resolving the alert in Towerops updates the PagerDuty incident as well.

How It Works

  • Device goes down → PagerDuty incident triggered (critical severity)
  • Alert acknowledged in Towerops → PagerDuty incident acknowledged
  • Device recovers / alert resolved → PagerDuty incident resolved

Configuration

1

Create an Events API v2 Integration in PagerDuty

In PagerDuty, go to <.code>Services → select your service → <.code>Integrations tab → <.code>Add Integration → choose <.code>Events API v2. Copy the <.code>Integration Key (routing key).

2

Configure in Towerops

Navigate to <.code>Organization Settings → <.code>Integrations tab → click <.code>Configure on PagerDuty. Paste your integration key and test the connection.

<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Event-Driven

Unlike other integrations, PagerDuty is event-driven — there is no periodic sync. Alerts are sent to PagerDuty in real time as they occur. No polling or sync interval is needed.

General Integration Features

Test Connection

Every integration includes a Test Connection button that validates your credentials and confirms Towerops can communicate with the external service before saving.

Sync Status

The Integrations tab shows the last sync time, sync status, and any errors for each configured integration.

<% "mikrotik" -> %>

MikroTik Configuration

Towerops supports read-only monitoring of MikroTik RouterOS devices via SSH. In addition to SNMP polling, SSH access allows Towerops to retrieve detailed system information and create configuration backups of your MikroTik devices for disaster recovery and audit purposes.

<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Read-Only Access

Towerops currently operates in read-only mode for MikroTik devices. Configuration changes, reboots, and other administrative actions are not supported. This ensures your device configurations remain unchanged by monitoring operations.

<.icon name="hero-server" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Cloud or Agent-Based Connections

Both SNMP polling and SSH connections to MikroTik devices can be performed from either Towerops cloud infrastructure or your remote poller (agent). For publicly accessible devices, cloud polling is the simplest option. For devices on private networks or when you prefer to keep SSH credentials on your local network, deploy a remote poller. The device assignment determines which poller handles both SNMP and SSH operations.

Security Best Practices

For security purposes, it is strongly recommended to create a dedicated read-only user account for Towerops rather than using an administrator account. This follows the principle of least privilege and minimizes potential security risks. Even though Towerops only performs read-only operations, limiting the account permissions provides defense in depth.

Creating a Read-Only User

Connect to your MikroTik device via SSH or terminal and execute the following commands to create a read-only user named <.code>towerops:

Step 1: Create a new user group with read-only permissions

/user group add name=readonly policy=ssh,read,test,api

Step 2: Create the monitoring user with a strong password

/user add name=towerops password={if @generated_password, do: @generated_password, else: "YOUR_STRONG_PASSWORD"} group=readonly <%= if @generated_password do %> <% end %>
<.button type="button" phx-click="generate_password" disabled={@password_generating} > <%= if @password_generating do %> <.icon name="hero-arrow-path" class="h-4 w-4 mr-1 animate-spin" /> Generating... <% else %> <.icon name="hero-sparkles" class="h-4 w-4 mr-1" /> Regenerate Random Password <% end %> <%= if @generated_password do %>

⚠️ This truly random password from random.org will only be shown once!

<% end %>

Step 3: Verify the user was created successfully

/user print detail where name=towerops

Permissions Explained

The <.code>readonly group includes the following permissions. Note that while these permissions are granted to the user account, Towerops only performs read operations and does not make any configuration changes:

Permission Description
ssh Allow SSH access to the device
read Allow viewing configuration and status (read-only)
test Allow executing diagnostic commands (ping, traceroute, etc.)
api Allow API access for automated monitoring
<.icon name="hero-information-circle" class="h-5 w-5 text-blue-600 dark:text-blue-400 flex-shrink-0 mt-0.5" />

Important Notes

  • The read-only user cannot modify device configuration
  • No write, reboot, or sensitive permissions are granted
  • Use a strong, unique password for the monitoring account
  • Consider restricting SSH access by source IP if possible

Configuring in Towerops

After creating the read-only user, configure SSH credentials in Towerops:

Organization-Level Configuration

Navigate to <.code>Organization Settings → <.code>MikroTik tab to set default SSH credentials for all MikroTik devices in your organization.

Site-Level Configuration

Navigate to <.code>Sites → select a site → <.code>Edit to override credentials for all devices at a specific location.

Device-Level Configuration

When editing a MikroTik device, you can specify unique SSH credentials that override organization and site defaults.

<.icon name="hero-shield-check" class="h-5 w-5 text-yellow-600 dark:text-yellow-400 flex-shrink-0 mt-0.5" />

Security Recommendations

  • Always use SSL/TLS for SSH connections (API-SSL on port 8729)
  • Store credentials at the organization or site level when possible
  • Rotate passwords periodically following your security policies
  • Monitor access logs for unauthorized SSH connection attempts
  • Consider using SSH keys instead of passwords (if supported by your setup)
<% "insights" -> %>

Network Insights

Network Insights provides proactive observations about your network health, gathered automatically from all connected data sources.

How It Works

Towerops continuously analyzes data from SNMP polling, Preseem, Gaiia, and other integrations to surface actionable findings. Insights are categorized by source, urgency, and type so you can focus on what matters.

Insight Types

  • Reconciliation Findings — Devices that exist in Towerops but not in Gaiia (or vice versa), data mismatches between systems
  • Performance Anomalies — Devices with unusual metric patterns detected by Preseem or SNMP baselines
  • Configuration Drift — Detected changes to device configurations that may affect performance
  • Capacity Warnings — Access points or links approaching utilization thresholds

Filtering & Management

Use the filter bar to narrow insights by status (active/dismissed), source (Preseem, Gaiia, SNMP, system), and urgency level. Each insight shows affected devices as clickable links so you can drill directly into the device detail page.

Dismiss insights you've reviewed to keep the active list clean. Bulk actions let you select multiple insights at once.

Tip: Insights run on a nightly schedule. Connect your Gaiia and Preseem integrations in <.link navigate={~p"/help?section=integrations"} class="underline"> Organization Settings to get the most comprehensive insights.

<% "network-map" -> %>

Network Map

The Network Map provides a geographic view of your sites on an interactive map. Sites with latitude and longitude coordinates are displayed as markers that you can click to view details.

Adding Location Data

Each site can have an address and/or latitude/longitude coordinates. You can set these in two ways:

  • Manual entry — Enter latitude and longitude directly in the site edit form
  • Geocoding — Enter a street address and click "Geocode" to automatically look up the coordinates using Google Maps

Geocoding Setup

Address-to-coordinate conversion requires a Google Maps Geocoding API key. Your administrator sets this as the GOOGLE_MAPS_API_KEY environment variable on the server. The map display itself uses OpenStreetMap and requires no API key.

Map Features

  • Interactive pan and zoom with OpenStreetMap tiles
  • Click any site marker to see site name, device count, and a link to the site detail page
  • Auto-fits the map to show all your sites
  • Summary stats showing total sites, mapped sites, and total devices
<% "api-tokens" -> %>

API Tokens

API tokens allow external applications and scripts to authenticate with the Towerops REST and GraphQL APIs. Each token is scoped to an organization and can be managed from your user settings.

Creating a Token

  1. Go to User Settings → API Tokens
  2. Click "Create API Token"
  3. Give the token a descriptive name (e.g., "Grafana Integration")
  4. Copy the token immediately — it will only be shown once

Using a Token

Include the token in the Authorization header: 

Authorization: Bearer your-api-token-here

Security Best Practices

  • Create separate tokens for each integration — don't reuse tokens across services
  • Revoke tokens you no longer need
  • Never commit tokens to version control
  • Store tokens in environment variables or a secrets manager

See also: <.link navigate={~p"/help?section=rest-api"} class="underline">REST API and <.link navigate={~p"/help?section=graphql-api"} class="underline"> GraphQL API for endpoint documentation.

<% "rest-api" -> %>

REST API

The Towerops REST API provides programmatic access to your monitoring data. All endpoints are under /api/v1/ and require a valid API token.

Available Endpoints

  • Devices — List, view, create, and update monitored devices
  • Alerts — Query active and historical alerts, acknowledge, and resolve
  • Sites — Manage sites and their device assignments
  • Agents — List remote pollers and their status
  • Check Results — Query monitoring check results and metrics
  • Organization Settings — Read and update SNMP/MikroTik configuration
  • Members & Invitations — Manage organization membership
  • Integrations — Configure Preseem, Gaiia, and PagerDuty
  • Activity Feed — Recent events and changes across the organization

Quick Example 

<%= raw("curl -H \"Authorization: Bearer YOUR_TOKEN\" \\\n  https://app.towerops.net/api/v1/devices") %>

All responses use {raw("{\"data\": ...}")} format. Results are scoped to the organization associated with your API token.

Full reference: REST API Documentation → — complete endpoint reference with request/response examples.

<% "graphql-api" -> %>

GraphQL API

The GraphQL API lets you query exactly the data you need in a single request. The endpoint is POST /api/graphql and uses the same API token authentication as the REST API.

Why GraphQL?

  • Fetch related data in one query — Get devices with their sites, alerts, and latest metrics in a single request
  • No over-fetching — Request only the fields you need
  • Introspection — The schema is self-documenting; use any GraphQL client to explore available types and fields

Quick Example 

<%= raw("curl -X POST https://app.towerops.net/api/graphql \\\n  -H \"Authorization: Bearer YOUR_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"query\": \"{ devices { id name ipAddress status } }\"}'") %>

Available Queries

  • devices — List devices with filtering and nested site/alert data
  • device(id) — Single device with full detail including sensors and interfaces
  • sites — Sites with nested device lists
  • alerts — Active and historical alerts with device context
  • agents — Remote poller agents and their assignments

Mutations

  • createDevice / updateDevice — Manage devices
  • acknowledgeAlert / resolveAlert — Alert lifecycle management

Full reference: GraphQL API Documentation → — complete schema reference with query examples and variable usage.

<% _ -> %>

Section Not Found

The requested help section could not be found.

<% end %>
""" end end