Schedules and headless mode

In every schedule you pick one flow and the profiles it should run over. A schedule cannot exist without a flow, so there is no rule that merely opens five profiles at nine and leaves them sitting there.

Each flow row tells you whether it has a schedule and when the next slot falls. One button opens every schedule in a single list, soonest first.

• Flow

  The automation to run. A schedule without one would be an alarm ringing at nothing.

• Profiles

  The ones the flow runs over, and all of them from your workspace.

• How often

  Every day, chosen weekdays, or every 1 to 24 hours.

• At

  Hours and minutes as HH:MM, in your own local time.

• At once

  From 1 to 5 profiles in parallel, so thirty profiles become a queue rather than thirty sign ins in one minute.

• Pause

  Pause and Resume without losing the settings.

The app carries a clock of its own and looks every 30 seconds for the schedules that are due. Your account stores them so they travel between your machines, and it never runs them.

That split is deliberate. Opening a profile needs its cookies, its fingerprint and its browser, and those live on your computer rather than in a datacentre. A proxy password from the team's proxy library is stored in the account sealed and arrives for the launch.

Every day at 9:00 means nine in the morning where you are sitting. Nine in the morning stays nine after a clock change, because twice a year a day is not twenty four hours long.

Move your machine to another time zone and the next slot stands at the new local time. A slot that is already due is not lost on the way, so a clock change never swallows the run you are waiting for.

Suppose the computer slept for three days and three slots did not happen. You do not get them now, and this is the most deliberate decision in the whole feature.

Thirty profiles waking at once, at an hour they never normally work, is exactly the burst that reads as a robot. Making up lost runs would produce that burst with our own hands.

A slot still fires if the app sees it within 30 minutes of its time. Later than that you find it in the missed count instead, and that count is of real slots, so a weekly schedule counts weeks.

1. 1

   You open the lid

   Within thirty seconds the app looks for the schedules that are due.

2. 2

   Overdue slots move forward

   Anything more than thirty minutes late lands in the future.

3. 3

   You are told what was lost

   One warning per schedule, naming the flow and the number of runs that did not happen.

4. 4

   Normal service resumes

   The next slot fires at its own time, with no queue behind it.

A due slot does not always turn into a run. You see each of these as a notification at the time and as a line you can read the next morning.

You cannot open more profiles than your plan covers, not even with two schedules due in the same minute. You read skips apart from run results, because a skip is not a run with a poor outcome.

Schedules live in the workspace, like the proxy library and the flow library. Anyone signed in can see them. The account accepts new and changed schedules only from a manager or above, because a schedule acts on other people's profiles.

A schedule aimed at a stranger's profile or at a flow that is not there is not accepted by the account, and it does not become an alarm that never rings. The app itself checks only that a flow and profiles are named.

A schedule set up in the app runs from the moment it is saved. One arriving from your account lands switched off on this machine until you press Run here.

Running with no window is the Run without a window (for automation) checkbox in the profile editor, not a checkbox repeated in four dialogs. The browser works as usual, the profile still shows as open, and Stop still stops it.

You tick the box once, and the Launch button, a group start, a flow and a schedule all follow it. A program on the same computer can ask through the local API to hide the window for one run: the launch obeys that request, while window tiling and password fill still read the box on the profile.

• Second windows inherit it

  A tab window opened by a flow does not pop onto the screen behind your back.

• Window tiling skips it

  Arrange windows leaves headless profiles out of the grid instead of leaving a hole in it.

• Password autofill stays quiet

  On the built-in engine the app fills your sign in details, and the hidden window is not pulled to the front. On ARMANOS Browser there is no autofill.

• Copies stay headless

  Duplicating a night profile gives another night profile, and batch templates carry the flag too.

• No background throttling

  A hidden window is not slowed down, so a flow inside it does not crawl.

ARMANOS Browser is started with --headless=new. The older mode was removed from Chromium and simply does not turn on in this build.

Choosing that mode hides nothing by itself: without a user agent of its own the engine still calls itself a headless build. To the site it is your profile's browser, because the user agent comes from that profile's fingerprint on every launch, window or no window.

The usual companion --disable-gpu we deliberately leave out, because it removes WebGL entirely and a browser with no WebGL is a louder signal than a browser with no window. A headless profile also opens on one address, and the rest of your addresses become tabs once the browser is up.