A forwarder we work with has a browser agent log into a customer portal every ten minutes. Over 6,500 times since late July. 6,498 of those logins succeeded. 22 failed. 18 came back with a warning. A success rate of 99.4 percent.
The rate is not the story. Anyone who stops there has not looked yet. The story sits inside one single run. In the lines it writes to the log. Those lines tell you whether an unattended process is trustworthy. Or just green by luck.
One afternoon run, 14:05, takes 30 seconds. Every second of it is a line in the log.
Login module, about one second. Three steps: fetch the credential from the vault. Submit the login form. Verify the login result. No password in the code. No password in a spreadsheet. The agent reads the secret only at login.
Export module, about 22 seconds. Three steps: calculate the time window. Request the export. Validate the export. The portal returns an XML file. With the current state of every open leg. These 22 seconds are the most expensive part of the run. The portal itself takes that long to answer.
Transform module, about 50 milliseconds. Three steps: parse the XML. Filter for legs with an open actual time. Sort by priority. This is where the portal's view meets our own TMS state. Anything the portal still shows as open, but the TMS already closed, drops out here.
Publish module, about 5 seconds. Two steps: build the work list. Hand it to the dispatch planner. The result now sits where dispatch already looks. No extra window. No extra portal.
Four modules. Eleven named steps. One log line per step. Not "run succeeded." Which step, how long, with what result.
A portal with no API still has an interface. Built for people. An agent that operates it has to find elements. The login field. The export button. The table with the open legs.
The easy way is position. The third field. The second column. The fourth button from the left. This way breaks with the next portal update. One new column, one moved field, and the agent clicks the wrong thing. Without noticing.
The better way is meaning. The field labeled "username." The button that reads "request export." The row with an order number. A portal update often changes the layout. It rarely changes the text a support agent on the customer's side still needs to read. These are exactly the changes that kill a selector built on position. A selector built on meaning survives them.
Both approaches can still fail. The difference is what happens next.
On August 24, between 20:26 and 21:26 UTC, the login fails four times in a row. Same error each time: HTTP 500. The portal itself is not answering. Every single crash gets caught by a mail fallback first. No noise. No alert for a person. After the fourth failure in a row, the pipeline pauses itself. For 120 minutes. The log does not just say "login failed." It says "login module failed, portal outage." Not a credential problem. The agent tells the difference. A wrong password, or a problem at the vendor's end.
On September 10, the same pattern repeats. Smaller. Two crashes ten minutes apart. "Remote end closed connection." Then a 30-minute pause. After three failures instead of four. Shorter pause, fewer failures. The rule scales with severity.
A third trigger has nothing to do with a crash. The run time itself. A run that takes 162 seconds, against a median of 28, is 5.8 times the usual duration. The pipeline pauses out of caution. The portal is still answering. Just slower, but you would notice. That is the moment a person at a screen would get impatient. The agent gets careful before it fails outright.
All three rules share one thing. The pause does not end at the next scheduled attempt. It ends only once a new run comes back normal. Without that hysteresis, the pipeline would restart right after every disruption. And fail right away again. Every ten minutes. All day.
The monitor does not show "run 08:15: error." It shows the section where the run stumbled. The exact error text. And, if there was one, whether a fallback already handled it. An error with a fallback and a successful mail send needs no attention at 8am. An error with no fallback needs it right away.
That is why an alert mail for every single error is the wrong reflex. 22 errors in seven weeks would be 22 mails. Most of them with nothing to do, because the fallback already caught them. The monitor collects a handling status instead. Open. Auto resolved. Waiting on the portal. Dispatch reads one line in the morning. Not 22.
A screenshot only adds value on a real deviation. Not on every run. Otherwise the monitor drowns in pictures. Login pages that look exactly like they always do.
A selector built on meaning holds up longer. Not forever. If the portal changes the text of a button too, that path breaks as well. Say, from "request export" to "export data." The only difference is how often that happens.
Hysteresis protects against flapping. But it also delays detection of a real, lasting outage. By up to two hours. For a ten-minute cadence, that is fine. For an hourly run with only a few appointments a day, the same rule would be too slow.
The split between "portal outage" and "credential problem" exists for one reason. Someone named both cases in advance. A new failure type nobody expected still lands in the log unclassified at first. The log is more honest than a success message. It is not a substitute for someone reading it when something new happens.
Two other posts go deeper. The first: A customer portal without an API is not a blocker. The second: "The job ran" is not proof of health. This post is only the inside view of one run. Not the underlying question.
How often does your portal process pause itself without anyone noticing? If you do not know, send me a week of login times. I will show you the log behind them in a process check.
