Govern
When Neblex can't be reached
An On-Prem Worker keeps working when it loses its connection to Neblex, for example during a network outage at your site. Flows placed on it continue to run, and everything they did appears in your workspace once the connection is back. Nothing is lost and nothing runs twice.
On a Worker cluster, runs that already started keep running on their member. While any member still reaches Neblex, Neblex keeps running the cluster's flows through it. When none does, each scheduled, polling and stream flow runs on one member, and the members agree before each run starts, so it does not run twice.
If that member goes down, another member takes its flows over once it is clear the first one stopped: it said goodbye on a clean stop, its machine answers but the Worker is not running, or a second member also lost it. A poll continues from where the first member stopped. In a cluster of two machines, when the other one simply goes silent, its flows wait until it or Neblex is back, because silence alone does not prove it stopped. If a flow's destinations are keyed so that a second run does no harm, turn on Safe to run twice under the run target in the flow builder; the other member then takes it over on silence too.
When members can reach neither Neblex nor each other, two of them can end up running the same scheduled run. The first run counts; Neblex records the second and sends an alert, so you can check the flow's destinations. Allowing HTTPS between the cluster's machines on its member port prevents this.
What starts while disconnected
| Flow starts with | While disconnected |
|---|---|
| A schedule | Runs on time. The Worker keeps the schedule itself. |
| Poll for changes | Keeps polling and starts a run for what is new. |
| A live stream (Kafka, RabbitMQ, NATS, MQTT, Redis and the other stream sources) | Keeps receiving. Every message is kept safely on the Worker before it is confirmed to the source, and starts its run there. |
| A webhook, a form or an app | Does not start. These are reached through Neblex and start again once it is reachable. |
| A run you start in the app (Run) | Does not start. It goes through Neblex. |
Only Active flows run. A flow is set Active in the Workflows list. Your monthly allowance never stops a run while the Worker is disconnected: runs past it go ahead and count as overage when they sync. As always, only completed runs count.
Steps that wait for Neblex
Most steps run on the Worker exactly as usual: transforms, code, files, EDI, connector and HTTP calls, AI agents and timers. A few need Neblex, and a run that reaches one of them waits there and continues by itself once the connection is back. It never fails because of the outage.
- Data Table steps.
- Form steps and Wait for event steps: the task or event arrives through Neblex.
- Sub-flows and AI agent tools that run on another Worker, a cluster or in the cloud.
- Connections protected with your own encryption keys, and sign-ins that Neblex renews for you.
When you save a flow placed on a Worker, and when you set it Active, Neblex lists anything in that flow that will not run or will wait while the Worker is disconnected.
When the connection is back
The Worker first hands over everything it ran while disconnected; only then does it take new work. While it does, its row shows Syncing N of M offline runs. The runs appear in your run history with their real start times and the note Ran offline on the Worker, with when they synced, and they count toward your usage like any other run. Positions of polls and streams carry over, so nothing is fetched or received twice. Runs that failed while disconnected arrive as one summary per Worker, not one alert per run.
Blocking, deregistering or deleting a Worker in the app while it is disconnected takes effect when it reconnects. To stop its work on the machine meanwhile, use its offline controls.
No time limit. A Worker keeps running its flows for as long as it is disconnected, whether that is minutes or days. Its row shows Offline. A cluster member disconnected for 5 days is shown as Dormant in its cluster. After 5 days, runs Neblex was still waiting on from that Worker end as Worker gone. Nothing is removed: when the Worker reconnects, it works as before and those runs take the outcome it reports.
What the On-Prem Workers page tells you
- Update required: the Worker runs a release Neblex no longer accepts. It keeps running its flows as if Neblex were unreachable but gets no new work; download the current release and replace the program to reconnect it.
- Security update required: Neblex raised the lowest release every Worker must run, for the reason shown. Update the Worker the same way.
- Clock off: the machine's clock is far from the correct time. Schedules keep the correct time anyway; turn on the machine's time synchronization.
- Offline control is not set up: you cannot yet pause flows on that machine while it is disconnected. See Offline controls.
- How local data is protected: the machine's TPM, Windows data protection or an owner-only key file, with what that protection covers.
Alerts tell you when a Worker goes offline and when it is back. For a cluster you get one alert when members drop, naming them, and one when the last of them is back. You are also alerted when two members ran the same scheduled run, when a pause made on a member while it was cut off reaches Neblex, and when a Worker needs an update or must be enrolled again. Choose them under Alerts.
Removing a Worker
Remove a Worker in the app: Deregister stops its credentials at once, Delete also removes it from the list. Removing a standalone Worker cancels every job and run on it and moves the flows placed on it to the cloud as Draft, so nothing of them runs until you set them Active again. Removing one member of a cluster moves its work to the other members, and the cluster's flows keep running there. Deleting a cluster cancels every active job and run on it, moves its flows to the cloud as Draft, and deregisters and deletes all its Workers; the app asks you to confirm, because it cannot be undone.
To clean up the machine, stop the Worker and run ./neblex-onprem-worker uninstall: it deletes everything the Worker kept there. Then delete the program file. Removing the Worker from your workspace is done in the app.