Count unsent field work, not just successful requests

Separate what the service knows from what it cannot see

The server can measure received commands, duplicate recoveries and rejected submissions. It cannot directly count a draft on a device that has never connected. A dashboard claiming zero pending work may only mean zero recently reported pending work.

Have connected devices report a small queue summary, subject to the product's privacy rules. Include the observation time and app version. Display stale device observations separately rather than treating them as current zeroes.

Measure at the business command level. A single report may produce several file uploads, retries and status requests, so HTTP success percentage is a poor completion measure.

Use age to find work that needs attention

Track the oldest unsent command, time from local submission to server receipt and time spent in a conflict state. Choose operational thresholds around the actual workflow. A same-day inspection report and a nonurgent equipment note may need different expectations.

An illustrative fleet reports 120 pending commands. One hundred and ten were created in the last ten minutes and ten have waited overnight. The small older group may deserve more attention than the larger fresh burst.

Keep authentication pauses, transfer failures and business conflicts separate. Increasing retry frequency will not resolve a revoked account or a disagreement about the current job revision.

Verify completeness as well as speed

Acceptance checks should confirm that each received report has its required attachments and that a repeated command produces one outcome. A receipt for metadata while the required photographs are missing should not count as a complete inspection.

Include local-save failures in device testing and support reports. They happen before the service sees a command, so a server-only success measure excludes precisely the work the user may have lost.

Use synthetic journeys to exercise restart and receipt recovery. Production telemetry can show frequency, while controlled tests establish whether the recovery mechanism behaves correctly.

Make the metric lead to an action

For each alert, name the person who can act and the information they need. Support may contact a worker about a stale device, while engineering investigates repeated schema failures after an update.

Avoid sending report text or photographs merely to diagnose queue age. Command identifiers, state categories and timestamps are often sufficient. The metric should help recover work without creating another unnecessary copy of its contents.