Main: Monitoring and Uptime

Updated

Main: Monitoring and Uptime

Overview

Use this page to understand how continuous monitoring works on the LoadGen platform, and how its two layers differ. The Monitoring and Uptime overview is the informational front door for the monitoring area, sitting in the Main section of the navigation menu alongside the other module overviews. It draws the moving parts as one diagram, sequences the work as a lifecycle, and links into the pages where each piece is configured.

Monitoring answers the question "is it working right now?", and LoadGen answers it at two depths. End-to-end monitoring runs synthetic user sessions: real client software driving a real workload against your application on a schedule, producing free-form measurements that tell you what a user is actually experiencing. Uptime monitoring runs lightweight availability checks: fast, frequent probes that tell you whether an endpoint is reachable and responding correctly. Deep sessions catch the slow login that no ping would reveal; frequent checks catch an outage within a minute. Alerting sits on top of both.

This page changes nothing and requires no configuration to open. The capability cards are navigation into the monitoring pages, and those pages keep their own licence and role gates.

Main: Monitoring and Uptime, full page

Key concepts

  • Synthetic user session - A scripted user journey executed on a schedule by an agent against your live application, producing timing measurements the same way a load test does, but continuously and at low volume. Measurements are free-form, so a workload can record whatever moments matter for that application. (related: End-to-End Monitoring: Profiles)
  • Monitoring profile - The configuration unit for end-to-end monitoring: the monitoring type (Web or Citrix), the agents that execute the workload, and whether monitoring is active or paused. (related: End-to-End Monitoring: Profiles)
  • Uptime check - A scheduled probe that tests whether a service endpoint is reachable and responding correctly, reported as Healthy, Degraded, or Unhealthy. The platform offers 23 check types, and check intervals go down to every 30 seconds. (related: Uptime Monitoring: Checks)
  • Incident - A failure record opened automatically when a check fails and closed automatically when it recovers, capturing the check, the failure reason, and the start and end times. Maintenance windows suppress incident creation during planned downtime. (related: Uptime Monitoring: Incidents)
  • Alert trigger and profile - The two-part alerting model: a trigger is the delivery channel (email, webhook, SMS, or WhatsApp), a profile is the condition under which an alert fires and which triggers it uses. Profiles are reusable across the Monitoring, Testing, and Uptime scopes. (related: Alerting: Triggers and Alerting: Profiles)

When to use it

  • When you need to decide whether a given target belongs in end-to-end monitoring, uptime monitoring, or both.
  • When you are setting up continuous monitoring for the first time and want the prerequisite chain in one view.
  • When you need to explain the difference between a deep synthetic session and a lightweight availability check.
  • When you are designing an alerting scheme and want to see where triggers, profiles, and check results connect.
  • When monitoring is running but nothing appears on a dashboard, and you want to re-check the chain from one place.
  • When you want a launch point into Profiles, Schedules, Checks, Incidents, Maintenance, or the monitoring dashboards.

Before you begin

  • No prerequisites for opening this page. It is informational and ungated.
  • End-to-end monitoring requires the LG054 licence module; uptime monitoring requires LG057. Without them, the respective pages show an activation card instead of the feature. Check entitlements on Infrastructure: Licensing.
  • End-to-end monitoring needs at least one registered platform agent and a workload assigned to a profile before it produces data. The licence banner on End-to-End Monitoring: Profiles shows your agent ceiling and current consumption.
  • A monitoring datasource must be configured on Configuration: Datasources before the End-to-End Monitoring dashboard has anything to read.
  • Alert delivery requires a notification account: SMTP for email, Twilio for SMS and WhatsApp, configured on Configuration: Notification Accounts.

Steps

Step 1

Open Monitoring and Uptime in the Main section of the left navigation menu.

Expected result: The overview page opens immediately, with the architecture hero at the top. It renders on an appliance with no profiles or checks configured yet.

Step 2

Read the architecture hero.

The diagram shows the two monitoring paths side by side: agents executing synthetic user sessions against your applications, and the platform running availability probes against your endpoints. Results converge on the dashboards and feed the alerting layer. Port chips label the network paths; remote monitoring agents connect outbound over HTTPS using API keys from Configuration: End-to-End Monitoring: Platform Agents, so no inbound firewall rules are needed for them.

Quantities drawn inside the diagram are illustrative and prefixed e.g.; they do not read your configuration.

Main: Monitoring and Uptime, architecture hero

Main: Monitoring and Uptime, lifecycle strip

Step 3

Follow the lifecycle strip.

The strip lays monitoring out as six ordered steps. The underlying chain, as documented across the monitoring pages, is:

  1. Point storage at a datasource. Set the monitoring datasource on Configuration: Datasources.
  2. Connect the agents. Register platform agents and issue their API keys on Configuration: End-to-End Monitoring: Platform Agents, and create the accounts sessions run under on Users.
  3. Define when it runs. Create the cadence on Configuration: End-to-End Monitoring: Schedule Definitions.
  4. Create the profile. Set monitoring type, agents, and workload on End-to-End Monitoring: Profiles, then verify coverage on the weekly calendar at Schedules.
  5. Add availability checks. Create probes on Uptime Monitoring: Checks, and book planned downtime into Maintenance so it does not raise false incidents.
  6. Watch and get told. Read the End-to-End Monitoring: Dashboard and the Uptime Monitoring: Dashboard, and wire delivery through Alerting: Triggers and Alerting: Profiles.

The page's lifecycle strip, From blind spot to early warning, in six steps, reads: 1 Create (a profile or check), 2 Assign (agents + test users), 3 Schedule (windows + intervals), 4 Observe (first sessions come in), 5 Alert (on the first failure), 6 Review (incidents + trends). The numbered list above expands those labels (verified).

Step 4

Use the capability cards to enter the module.

Each card names one thing monitoring does and links to the page where you do it. Selecting a card is read-only navigation; no check is triggered and no profile is changed from this page.

Main: Monitoring and Uptime, capability cards

Step 5

Read the pulse chips, if present.

This page can surface real counts the platform already holds, for example the number of configured uptime checks and how many incidents are currently open. Treat these as orientation only; the dashboards are the authority for anything you intend to act on.

Next steps

Verify the result

The page is working correctly when the architecture hero renders as a diagram, the lifecycle strip shows its steps, and the capability cards navigate into the monitoring pages. Nothing is saved here, so there is no state to confirm. If a capability card opens a page showing an activation card instead of the feature, that is the target page's licence gate rather than a fault on this page.

Troubleshooting

  • Symptom: A capability card opens a page showing an activation card with Activate License and Learn More. Fix: End-to-end monitoring (LG054) or uptime monitoring (LG057) is not licensed on this appliance. Check Infrastructure: Licensing. This overview page is ungated by design and describes both regardless.
  • Symptom: The lifecycle mentions Schedule Definitions or Platform Agents, which are not in your navigation menu. Fix: CONFIGURATION: END-TO-END MONITORING is an Expert-mode section; switch the sidebar footer toggle to Expert.
  • Symptom: You find two entries named Schedules and cannot tell them apart. Fix: End-to-End Monitoring: Schedules is the read-only weekly calendar; Configuration: End-to-End Monitoring: Schedule Definitions is where you create and edit them. The calendar has a Manage Schedules cross-link, which is only visible in Expert mode because its target is an Expert-mode page.
  • Symptom: Profiles are enabled but the End-to-End Monitoring dashboard is empty. Fix: Confirm a monitoring datasource is set on Configuration: Datasources and that the agents in the profile are connected.
  • Symptom: Planned maintenance raised incidents and alerts. Fix: Create the window in advance on Uptime Monitoring: Maintenance; checks assigned to an active window stop executing and do not generate incidents.
  • Symptom: A quantity in the diagram does not match your environment. Fix: Numbers prefixed e.g. inside the diagram are illustrative examples, not readings of your configuration.
Was this article helpful?
0 out of 0 found this helpful