Separate browser health from export health in your automation

Your worker connects to a browser, opens the supplier portal, and exits without an exception. The monitoring panel turns green. The finance team still has no usable invoice.

The missing piece is a second health signal: did the business task produce the agreed result?

When evaluating hosted browser infrastructure and agent workflow tooling, I would keep those signals separate. This article proposes a small record and incident-routing exercise. It is not a test result for BrowserAct, Browserless, or any invoice portal. We publish it from the BrowserAct team.

Give each signal a narrow meaning

For this design, browser health answers a technical question: could this worker establish and use the intended browser connection during a particular observation window?

Export health answers a different question: did the requested account, period, and document set produce an accepted artifact?

Neither signal should stand in for the other. A connection probe cannot prove an invoice is correct. A valid file saved earlier cannot prove the browser is currently reachable.

Keep timestamps with both observations. An old green result is especially misleading after a worker restarts or a session expires. Also record which account reference and execution environment were involved, without copying credentials into the incident ticket.

Start with a record that permits uncertainty

Here is a fictional application-side record. These fields are a proposed convention, not either vendor's API schema:

{
  "job_id": "demo-export-042",
  "account_ref": "supplier-account-demo",
  "requested_period": "2026-10",
  "runtime": {
    "status": "reachable",
    "observed_at": "2026-11-07T05:00:00Z"
  },
  "workflow": {
    "status": "awaiting_artifact",
    "last_confirmed_step": "export_requested",
    "request_ref": "demo-request-91",
    "observed_at": "2026-11-07T05:01:00Z"
  },
  "artifact": {
    "status": "not_verified",
    "manifest_ref": null
  }
}

This job is pending, even though its runtime observation is green. Do not convert it to success because the worker returned a zero exit code.

The request reference is useful only if you actually observed one. If the portal supplies none, keep it absent and describe the evidence you do have. Never manufacture an ID to make the record look complete.

Route the next investigation by evidence

A small decision table makes ownership clearer:

Latest evidence	Next investigation
Browser connection failed before page access	Runtime or connection owner checks the environment
Browser reachable, portal asks for login	Authorized account owner handles authentication
Export request acknowledged, file still pending	Workflow owner checks the existing request status
File exists, account or period does not match	Acceptance owner rejects and investigates the artifact
File accepted, delivery destination unavailable	Delivery owner resumes delivery from the saved artifact
Submission outcome uncertain	Inspect current portal state before considering another submission

These are investigation routes, not automatic permission to retry. In particular, a connection loss after submission does not establish that the server rejected the action. The last confirmed step matters more than the final exception text.

If the evidence is too weak to choose a route, label the state unknown and name the person or check that can resolve it. Avoid turning missing evidence into a guessed technical diagnosis.

Keep the business acceptance rule explicit

For invoice collection, a file-extension check is insufficient. A proposed acceptance rule could include the intended supplier account, billing period, readable content, expected document identifiers, and a manifest of unresolved items.

The expected set needs a source. If you only know that three files were downloaded, you cannot infer that the month contains exactly three invoices. Store the observed count and mark completeness unknown until you can compare it with an authoritative list.

Assign acceptance a version. When the rule changes, retain the earlier result and identify which version produced it. That prevents a dashboard from quietly rewriting historical success after the definition changes.

Rehearse ownership before choosing a provider

Use a test account or synthetic exercise to walk through four situations: a failed connection, an expired login, a delayed artifact, and a failed delivery destination.

For each, ask who detects the condition, who can inspect the evidence, who is allowed to act, and how the task resumes. Write down the actual answer, including responsibilities that remain with your own team.

Then evaluate the candidate implementation against those same situations. A provider may help with several layers; your contract still needs to identify the integration boundary. Do not infer that a service owns an entire recovery process simply because it exposes one relevant feature.

This exercise can be completed as a tabletop review before live testing. Label it accordingly. A convincing walkthrough is not proof that the production workflow survives an outage.

Report three outcomes instead of one green light

At minimum, show runtime observations, accepted business jobs, and unresolved jobs separately. Add the age of the oldest unresolved task so a quiet queue does not hide stalled work.

For an individual job, link to its accepted artifact or explain the remaining verification step. For recurring reports, keep failures and unknowns in the denominator. That gives an operator something concrete to investigate instead of a reassuring connection metric.

Our BrowserAct vs Browserless guide explores the infrastructure and workflow distinction. The record above is one way to make that distinction reviewable in your own evaluation.

Who owns the gap between a healthy browser and an accepted export in your current system?