Verifying and troubleshooting runner connectivity

After you install a runner, this article helps you confirm it is connected and checking in, read its poll logs, and work through the most common connectivity failures. It is for the technician who has just installed a runner.

We'll cover five main steps:

1. Confirming the runner is online
2. Reading the poll logs
3. Interpreting common failures
4. Cached secrets and restarting a runner
5. The gpt-5.4 quota two-pass install

Step 1: Confirming the Runner Is Online

Why are we doing this? This is the check that tells you the install actually worked and the runner is talking to the control plane.

After deployment, the runner should display as online on the Runners page within about two polling intervals (roughly two minutes at the default 60-second cadence). The runner's last-seen time and version update on its first successful poll. If the runner does not appear within about five minutes, check its poll logs.

Check each application, not just the runner as a whole. The runner’s detail page shows a version grid with one row per instance and one column per runner script; each version is green while that application is checking in and red when it is not, with its last check-in on hover and not polling shown beneath it. A runner reads as online while any one of its applications polls, so this grid is how you catch a single script that has stopped while its siblings carry on.

Step 2: Reading the Poll Logs

Why are we doing this? The poll logs show whether the runner is reaching the control plane and what response it gets, which is where you look when it is not online.

Each runner Function App writes poll activity to Application Insights. Script runners log lines prefixed with PollTimer: while agent runners use AgentPoll: prefixes. On each timer firing, the runner signs a check-in and posts it to the control plane to lease work and report health status. Successful ticks with no work show no-content results; ticks that lease work display the dispatched item. Review these lines to determine whether the runner reaches the control plane and what response it receives.

Step 3: Interpreting Common Failures

Why are we doing this? Most connectivity problems come down to a few specific responses, and knowing them points you straight at the fix.

• 401: The control plane rejected the runner’s signature because the secret the runner is signing with does not match the one stored at registration. Rotate the runner secret from its detail page and apply the new value, or re-run the installer with the correct one. If one application 401s on every poll while the others in the same runner are healthy, it is usually a fresh install whose permissions had not finished propagating when that application started; a full stop, a five-minute wait, and a start of that application — not a restart — clears it (see below), and the runner now reports this as a missing credential instead of failing silently.
• 410: The runner has been revoked. It records a retirement marker, stops polling, and short-circuits on later attempts. Register a new runner and reinstall to restore functionality.
• Egress timeouts: The runner cannot reach the control plane or package store. In restricted environments, confirm the outbound allow-list and review Runner network and egress requirements.

Step 4: Cached Secrets and Restarting a Runner

Why are we doing this? A runner reads its Key Vault settings when its process starts and holds them for the life of that process. If you change a secret and the runner keeps behaving as though the old value were still in place, the cached value is almost always the reason — not the secret itself.

Important -> A restart is not enough on a Flex Consumption runner. Stop the Function App, leave it stopped for at least five minutes so the cached value is cleared, then start it again. Restarting in place, or stopping and starting straight away, can hand the app the same cached value it had before, and the symptom survives untouched.

Use this whenever a secret change has not taken effect — after rotating the runner secret, after changing the AI provider or its key, or after adding an extension credential. Apply the same stop, wait, start sequence to each application you changed. For the secret-editing steps themselves, see Accessing and updating your runner’s Key Vault.

Step 5: The gpt-5.4 Quota Two-Pass Install

Why are we doing this? New subscriptions often lack the AI model quota, and knowing how the installer handles it explains an alert you may see and how to clear it.

New subscriptions lack gpt-5.4 quota, which is checked during deployment preflight. To avoid aborting, the installer deploys in two passes: pass one deploys infrastructure and the Foundry account (no quota needed), and pass two deploys the gpt-5.4 model on a best-effort basis. If quota is missing, pass two prints an action-required alert and exits cleanly, so the runner still deploys and polls normally.

When you see the alert, AI activities will fail until quota is granted. Request gpt-5.4 GlobalStandard quota for the subscription and the Foundry account's region in the Azure portal's Quotas area, then re-run the install command. Pass one becomes a no-op and pass two adds the model.

Note: Request higher quota when enabling the agent runner, since its bundled Foundry draws from the same quota.

Once the runner shows online and any quota alert is cleared, the initial setup is complete and the runner is ready for its first workflow. When you are ready to build automations, see Creating your first workflow in the Designer.

If you are still having trouble, we're here to help! Submit a ticket here for assistance, and don't forget to check our status page to ensure there are no outages in your area.