What Should a Connected Machine Do When the Internet Goes Down?

Your connected machine will eventually lose internet access. The useful question is what it should do during that outage. Should an active cycle finish? Should the next customer be allowed to pay? Can a technician diagnose the machine locally? Those are product and engineering decisions, and they should be settled before the first field outage settles them for you.

Edge versus cloud architecture explains where functions can live. This article turns that architecture into a behavior contract for disconnection, degraded service, and recovery. Offline is a collection of conditions, not one instruction to reboot the router.

1. Classify functions by dependency and consequence

List local sensing, actuation, interlocks, UI, payment authorization, configuration, inventory, telemetry, updates, and support. For each, identify the information required, where authority resides, acceptable staleness, and consequence of losing access. A local temperature display and authorization for a new paid service do not need the same outage policy.

Do not move a time-critical or safety-related response to a remote service merely because the product has an IoT dashboard. The appropriate local control and safety architecture need their own assessment and verification. Define which functions continue independently, which degrade, and which stop taking new work. Reliable machine control provides the broader control context.

2. Distinguish network presence from service availability

A Wi-Fi connection does not establish usable internet, and internet access does not establish an authenticated session with your backend. Model link state, addressing, name resolution, secure connection, authentication, and application response separately enough to diagnose failure. A green signal-strength icon can be technically accurate while telling the operator almost nothing useful.

Use timeouts and retry backoff appropriate to the application, with an explicit service state. Record the last successful exchange and its meaning. Do not repeatedly reset the controller because an external service is unavailable; that can interrupt local work without fixing the upstream problem. Give technicians the failed layer and a bounded diagnostic path.

3. Decide what happens to work already in progress

An authorized local operation may be able to finish without internet if its prerequisites, control, and evidence are available locally. Define this explicitly. Other operations may need a controlled hold or stop. A connection loss must not bypass interlocks, extend an output indefinitely, or cause an automatic restart of a physical sequence.

Retain the operation identity and outcome durably. If the server cannot receive the result, upload it later without repeating the physical action. Watchdog and recovery design covers reboot behavior; connection loss is a different event but needs the same clarity about what the mechanism has already done.

4. Set an explicit policy for new purchases

If the machine cannot verify a new payment or obtain the required authorization, stop offering that purchase flow. Showing a QR that can collect money while the machine cannot fulfil is a business decision with recovery consequences, not a harmless screen fallback. Clear stale purchase resources according to the payment design and give the customer an accurate availability message.

Any offline authorization scheme needs a separate review of limits, trust, reconciliation, fraud exposure, inventory, and support. It must not arise accidentally from accepting a screenshot or an old paid flag. Dynamic QR integration and payment recovery explain the relevant transaction boundaries.

5. Store important facts within a defined capacity

Classify logs and events by importance. Transaction outcomes, unresolved operations, and service-critical faults usually need stronger retention than frequent normal telemetry. Define queue capacity, record identity, persistence, upload acknowledgment, and what happens when capacity is reached. A queue that grows forever is a delayed storage fault.

Estimate storage from event rate, record size, expected outage, and overhead using measured formats. For an illustrative calculation, 120 records per hour at 200 bytes each for 48 hours is 1,152,000 bytes before indexes, integrity data, and reserve space. That is a planning example, not a product requirement. Test the actual implementation and define what may be summarized or dropped with a visible loss counter.

6. Treat queued commands differently from queued facts

A historical temperature observation is still a historical fact. An old unlock command can become hazardous or commercially wrong when executed hours later. Commands need identity, authorization, target, configuration compatibility, validity, and current-state checks. Reconnecting a transport must not automatically make every queued action eligible.

Separate desired configuration from one-time physical operations. Reconcile the current version before applying settings, and preserve the same operation identity when retrying an eligible action. Duplicate dispensing prevention explains why re-delivery should return a stored result rather than launch another attempt.

7. Specify the reconnection sequence

Restore authenticated communication, establish the current machine and software identity, exchange relevant sequence or version information, upload retained results, reconcile unresolved operations, and refresh permitted configuration. The exact order depends on the product, but the sequence should protect physical operations from obsolete state.

Include interrupted reconnects and repeated reconciliation. The process should resume without deleting unacknowledged facts or authorizing work twice. Report clock uncertainty rather than inventing precise event times. Fleet dashboard requirements should expose both last contact and unresolved recovery so an operator can see what ready actually means.

Function and local owner:
Information and authorization dependencies:
Behavior during partial or complete disconnection:
Active-operation response and retained evidence:
New-work eligibility and customer message:
Queue capacity, priorities, and overflow response:
Command validity and obsolete-message rejection:
Reconnection, reconciliation, and readiness criteria:
Local service access and acceptance tests:

8. Test the outage the technician will encounter

Test a dead access point, unusable internet behind a working link, name-resolution failure, rejected authentication, backend downtime, high latency, repeated drops, and long disconnection. Interrupt an active transaction and fill the offline queue in a controlled setup. Confirm local control, customer messages, logs, and eventual reconciliation.

Provide service instructions that distinguish site network work from controller faults. Local access should remain appropriately authenticated and limited even during an outage. A temporary diagnostic mode must not silently become an unrestricted actuation path. Record what a technician can inspect without cloud access and which actions require later approval.

9. Make offline behavior part of the purchase specification

Bring deployment conditions, active-cycle requirements, payment flow, storage resources, service expectations, and the longest outage the design is intended to support. Identify which promises require connectivity and what the customer sees when those promises cannot be met. This prevents an online demo from becoming an accidental field specification.

SolveMpire can discuss connected-machine firmware and integration with a function-by-function outage matrix and failure test plan. The objective is predictable behavior and recoverable evidence, not pretending every machine can provide every service without a network.