How to Tell Whether Anything Is Actually Hosting Your Syncs

A healthy integration host with nothing due writes no run rows at all, so an empty run history and a plant with no host running look identical. EDGEBIC by User Solutions closes that gap with a separate liveness beacon that every host stamps on a short cycle, including workstations that have been told to host nothing.

This post is about reading that signal, which is the difference between knowing your syncs are running and merely not having seen them fail. For the argument about where hosting should live, read why your ERP sync belongs on a server.

The Question Run History Cannot Answer

Run history is excellent at what it does. Every run writes a row before any work begins and finalizes it when the run ends, so a run is visible even if it fails halfway, and a crash leaves a detectable interrupted row rather than a silent gap. Reading run logs and run history covers that surface in full.

But run history is a record of things that happened. It has nothing at all to say about things that never started.

Consider two sites at eleven in the morning, both with an integration on a fifteen minute interval, both showing an empty run history for the last hour.

The first has a host running normally and no rows because the source has produced no changes worth importing. Everything is fine.

The second has no host at all, because the last workstation with hosting enabled was replaced in June and nobody noticed. Nothing has run since. Nothing has failed either, because failing requires attempting.

From the history alone, those two sites look the same. That is the problem the beacon exists to solve.

What the Beacon Reports

Every EDGEBIC process capable of hosting stamps a small liveness record on a regular cycle of about thirty seconds. The record says who it is, what kind of process it is, and when it last checked in. That is all it needs to say.

Because it stamps on a timer rather than when work happens, it answers the question run history cannot: something is alive, right now, and it is this.

Crucially, it keeps stamping while a host is paused. Pausing an EDGEBIC host stops schedule dispatch and file watching, so no runs fire and no rows appear, but the process itself is alive and continues to say so. That single decision is what makes "paused" distinguishable from "dead", which are two very different problems with two very different fixes.

The Consumer Beacon

The most easily overlooked part of this design is what a workstation that hosts nothing reports.

On a shared database with a server service, the correct configuration is that every planner's workstation has hosting turned off. Such a workstation dispatches nothing, so it writes no run rows. If it also wrote nothing else, it would be indistinguishable from a workstation that is switched off, or one where nobody signed in today.

So it still stamps a beacon, marked as a consumer rather than a host. The meaning is precise: this application is running, it is connected to the shared database, it is picking up changes made elsewhere, and it is deliberately dispatching nothing.

That matters in two moments.

During a rollout. You turn hosting off on twelve workstations and want to know it took effect. Twelve consumer beacons is proof. Silence is not, because silence could mean the setting worked or could mean nobody opened the application.

When you are counting hosts. Anything asking "is something actually hosting?" has to exclude consumers from the count. A consumer beacon is evidence of a healthy workstation, and it is not evidence that anybody is dispatching your nightly ERP pull. Reading a consumer as a host is the one way to misread this signal, and it produces false confidence at exactly the wrong moment.

The Four States, and What Each One Means

The third row is the one to watch for after a rollout, because it is the natural consequence of doing half of a correct change: turning hosting off everywhere is right, and it is only right once the replacement is running.

The Diagnostic Order

When somebody reports that a scheduled integration did not fire, work outward from the host. Each check is cheaper than the next, and most reports stop at the first two.

1. Is any host alive and recently seen? If not, nothing could have fired, and no other check will tell you anything.
2. Is that host paused? Pausing stops dispatch while the beacon keeps stamping, which is exactly the state that looks alive and does nothing.
3. Is the integration enabled, and is its schedule enabled? These are two separate settings and either one alone will keep it quiet.
4. Has a full interval actually elapsed since the last dispatch? The interval is measured from one dispatch to the next rather than from a wall clock time, so an integration that ran at 10:07 on a fifteen minute interval is next due at 10:22, not on the quarter hour.
5. Was a run already in flight? A second attempt against an integration already running is refused rather than duplicated, and it will be retried on the next tick.

For file-watched integrations, add one more: the watched folder has to exist when the host starts. A folder that is missing, or a mapped drive the service account cannot see, results in a watcher that is skipped rather than one that fires and fails.

Two Things the Beacon Does Not Do

It does not tell you an integration is producing good data. A host can be perfectly alive and importing rows that map to the wrong fields. That is what run rows, per-row outcomes and counts are for.

And it is not an alert. Nothing emails you when a beacon goes stale, so the useful practice is a short weekly look: are the hosts I expect present, are their last-seen times recent, and are the workstations reporting as consumers rather than as hosts. That takes under a minute and catches the silent case that nothing else will.

For the wider set of routine checks on a shared deployment, read keeping the EDGEBIC database healthy over time, and the full administrator reference is the EDGEBIC admin guide.