Just a small footnote - one thing I have noticed in common with some customers experiencing this issue, is that they have combined the Login process in a Schedule alongside other tasks.
As the Login process involves establishing a connection with the Login Agent resource, asking it to log the machine in, and then closing this resource down, and then bringing online the normal resource instance before it is in a state to successfully run any other process, it is not best practice to place all these tasks in a single Schedule unless some kind of appropriate length gap is left between the Login and the process to be run, and also suitable checks are made to ensure the normal resource is online and ready to run normal processes.
For example, the original poster shows that it is often the task after the Login which fails - this could be because not enough time has been left to ensure the normal resource is online - hence it reporting an offline problem.
It is also worth bearing in mind that frequent logging in and out of a resource, relies on this working perfectly every time. Unless there is a need to switch user, we would suggest it might be better to set up a Schedule just to log all resources in, and then rather than logging in and out between process runs, to alternatively lock and unlock the screen, which still ensures they are password secured when not in use, but a lock and unlock will occur much faster than a login and a logout, and there is less risk of the machine being left in the wrong state.