ControlUp Synthetic Monitoring Workflows and Workarounds

A user named Alexander asked Nathan about a known limitation with ControlUp Synthetic Monitoring – specifically, that the server_name is often empty for NetScaler Gateway scouts. Nathan recommended a few different workarounds for auto-restart and suggested adding more fields to the webhook payload for debugging. The suggested workflow was to use resource and query ControlUp Real-Time DX / CVAD for machines or sessions matching the published resource.

Read the entire ‘ControlUp Synthetic Monitoring Workflows and Workarounds’ thread below:

Hello Alexander. I am not a workflows guy, but I ran you question through our analysis tool and this is what I got back:

This is a known limitation with ControlUp Synthetic Monitoring → Workflows, not a misconfigured webhook. Your setup looks correct; the variable is often simply not populated for NetScaler Gateway scouts.

What you have right

• Custom field name:server_name

• Value:{test.server_name}— this is thedocumented syntax

• Webhook → Workflow path is working:resource: "Virtual Workplace"shows variable substitution is happening

So the pipeline works. {test.server_name} resolves to "" because the scout run has no server name to send.

Why server_name is empty

Per ControlUp docs, {test.server_name} means:

The server on which the Scout’s session was opened (for EUC Scouts)

It is only set when the scout successfully lands a session on a specific host/VDA. For NetScaler Gateway scouts, that is often missing because:

1. Gateway scouts don’t resolve VDA hostname the same way— Custom Hive broker/DDC metadata collection applies mainly to internal Citrix StoreFrontscouts, not external NetScaler Gateway paths via Cloud Hive.
2. Failure alerts have no server— If the alert fires when the scout fails (auth, ICA launch, session timeout), no session host is assigned yet. That is the most common auto-remediation scenario.
3. Platform differences—server_nameis reliably populated for VMware Horizon and AVD scouts on successful runs; Citrix Gateway / Citrix Cloud paths are less consistent.

First check: In Synthetic Monitoring, open a successful test result for this scout. If server_name is blank there too, the webhook cannot send it — this is a data availability issue, not a workflow mapping issue.

Also note: the webhook Test button can send empty strings for some variables. Validate with a real alert or a forced scout failure.

Recommended workarounds for auto-restart

Option 1: Use resource + lookup (most practical today)

You already receive resource. Build the workflow like this:

1. Webhook triggerreceivesresource,scout_name,fail_code, etc.
2. Query ControlUp Real-Time DX / CVADfor machines or sessions matching that published resource (e.g. delivery group / app name = "Virtual Workplace").
3. Restart the affected machine(s) via a Citrix/VDI workflow action or PowerShell.

This is less precise than a single server_name, but works when the scout cannot identify the VDA.

Option 2: Internal StoreFront scout + Custom Hive

If you need server_name in the webhook payload:

• Use aCustom Hive with an internal Citrix StoreFront scout (not external NetScaler Gateway).

• The hive can query XenDesktop brokers for session/machine metadata.

• Trade-off: you monitor from inside the network, not through the external gateway.

Option 3: Real-Time DX triggers for host-level remediation

For "restart the affected terminal server," synthetic monitoring is better at detecting user-facing failures. Host-level remediation often fits better with:

• Real-Time DX alertson VDA registration, session failures, or machine stress

• AListener triggerworkflow using{{Start.event.associated_id}}to target the specific machine

That gives you the machine identity synthetic monitoring may not have.

Option 4: Broader pool restart (use with caution)

If the published resource maps 1:1 to a small delivery group, restart all machines in that group when the scout fails. Higher blast radius — only use if the pool is small and dedicated.

Suggested webhook payload

Add more fields while debugging:

Custom fieldValueresource

{test.resource}

server_name

{test.server_name}

scout_name

{test.scout_name}

scout_address

{test.scout_address}

fail_code

{test.fail_code}

fail_reason

{test.fail_reason}

In the workflow Start node, map these as Input Variables and inspect a test run log to see what actually arrives (community pattern: {{Start.server_name}}, {{Start.resource}}, etc.).

Example remediation flow

Synthetic Alert (NetScaler Gateway scout fails)

→ Webhook to Workflow (resource + fail_code)

→ List Devices / CVAD query (filter by published app or delivery group)

→ If count = 1: restart that VDA

→ If count > 1: restart least-recently-used / notify ops

→ Log action + optional ServiceNow ticket

Bottom line: Yes, this pattern is used — webhook → workflow for synthetic remediation — but {test.server_name} is often empty for NetScaler Gateway scouts, especially on failures. Plan around resource + Real-Time DX/CVAD lookup, or switch trigger source for host-specific actions.

Hey Nathan,

thanks a lot for your detailed response. I’ll have a look at it.

Thanks!

Continue reading and comment on the thread ‘ControlUp Synthetic Monitoring Workflows and Workarounds’.  Not a member? Join Here!