Schedules and headless mode

Every schedule points at one flow, the automation you built in the builder, and at the profiles it should run over. A schedule cannot exist without a flow. There is no rule that only opens five profiles at nine and leaves them sitting there.

Three repeat rules exist. Daily fires at a chosen time. Weekly fires at that time on the weekdays you tick. Hourly fires every N hours, where N is between 1 and 24, counted from the moment it last fired.

At once decides how many profiles the run keeps open in parallel, from 1 to 5. The app clamps that number and the server refuses anything outside the range. Thirty profiles with At once set to two become a long queue, not thirty sign ins in one minute.

In the app, each flow row says 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

  Which profiles the flow runs over. The server checks that every id belongs to your workspace.

• Repeat

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

• Time

  Written as HH:MM, in your own local time.

• At once

  1 to 5 profiles in parallel.

• Enabled

  Pause and resume without losing the settings.

The desktop app carries a clock of its own. Every 30 seconds it asks which schedules are due and starts the ones that are. Your account stores the schedules so they travel between your machines. It never runs them.

That split is deliberate. A run needs the profile's cookies, its fingerprint seed, its proxy password and its browser, and all of those live on your machine. Running it from a datacentre would mean uploading your sessions and opening your accounts from an address the profile never normally uses.

The consequence is stated in the window itself instead of being hidden in a help page. No background service is installed, so a closed laptop runs nothing. Sleep counts as closed.

One more thing follows from it. Two computers signed into the same account must not fire the same schedule in the same minute, and the app takes care of that. The section below says how.

Every day at 9:00 means nine in the morning where you are sitting. The next run time is worked out by walking calendar days, not by adding twenty four hours in milliseconds. Twice a year a day is not twenty four hours long, and the simple sum would slide the run by an hour.

Each schedule also remembers the timezone offset it was calculated in. When the app starts and sees a different offset, after a daylight saving change or after you flew somewhere, it recalculates the next time from scratch.

A slot that is already due survives that recalculation. Without the exception, a clock change or a move would silently swallow the run you were waiting for that very minute.

Suppose the computer slept for three days. Three slots did not happen. The app does not run them now, and this is the most deliberate decision in the whole feature.

Thirty profiles waking up at once, at a time of day 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, inside a product bought to avoid it.

A slot still fires if the app sees it within 30 minutes of its time. Later than that it is stale: the next time is walked forward into the future and the slot is counted as missed. A warning names the flow and how many runs did not happen. The count comes from counting real slots, so a weekly schedule counts weeks, not days.

Run now is separate. It starts the flow immediately and does not touch the next scheduled time. Pressing it at eight in the morning does not cancel the nine o'clock run.

1. 1

   You open the lid

   Within thirty seconds the scheduler runs its next tick.

2. 2

   Overdue slots move forward

   Anything more than thirty minutes late is walked forward until its next time 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. Nothing is queued up behind it.

A due slot does not always turn into a run. Four situations stop it, and each one raises a notification at the time and leaves a line you can read the next morning.

The plan quota applies to schedules too, and it is counted across the whole tick, so two schedules due in the same minute cannot open double. The quota is the plan's profile count: 2 on Free, 10 to 100 on Professional, 200 to 1000 on Business, 5000 and up on Enterprise. A subscription has 3 days of grace after its renewal date, and the app keeps working up to 24 hours without reaching the account.

Skips are stored apart from run results. Last run 09:00, no failures and skipped 11:00, everything already open are two separate lines, because a skip is not a run with a poor outcome.

The outcome itself is stored as a sign rather than a sentence: ok, stopped, or error:2/5. The words are chosen when the line is drawn, in the language of whoever is looking, so the same schedule reads correctly on a colleague's machine. At the start only started is written, because a flow over twenty profiles takes hours; the real outcome is written back when the run ends, and a run that fell over entirely counts as a failure.

Schedules are stored per workspace, like the proxy pool and the flow library. Anyone signed in can see them. Creating, editing and deleting them needs manager rights or above, because a schedule acts on other people's profiles.

The server checks the shape before it stores anything. The flow has to exist in this workspace, and every profile id has to belong to it as well. A schedule aimed at a stranger's profile, or at a flow that is not there, is refused rather than saved as an alarm that never rings.

When a schedule reaches your second machine it arrives marked not on this machine, with a Run here button beside it. Two open computers firing one schedule in the same minute would show every site two sessions of one account from two places, which is the behaviour the product exists to prevent.

Pausing from the account does reach the machine, because the enabled flag travels with the rest of the settings. An edit made here and not yet pushed wins over what the server returns, so your change is not overwritten in the second before it is sent.

Running without a window is a checkbox in the profile editor, not a checkbox repeated in four dialogs. The browser works as usual, it just does not appear on screen. The profile still shows as open, and Stop still stops it.

The decision is read once, at the top of the launch, and every road into that launch reads the same answer. The Launch button, a group start, a flow run, a scheduled run, the local HTTP API and the MCP server all arrive at the same place.

One override exists, and it is meant for programs rather than people. POST /api/v1/browser/start accepts headless in the body or in the query string, so a night script can hide a profile you normally use with a window. The values 0, false and empty mean no, because a query string carries text and a non empty string is not automatically yes.

• 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

  The sign in details are filled, but the hidden window is not pulled to the front.

• 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, not with the bare --headless. The old mode was removed from Chromium and simply does not turn on in build 153.0.7978.0.

Choosing the new mode hides nothing on its own. Measured on the built Windows engine 153.0.7978.0 on 4 September: with no user agent switch the browser calls itself HeadlessChrome/153.0.0.0 in the new mode as well. What keeps that string out is the --user-agent value taken from the profile fingerprint, which is passed on every launch, window or no window.

The usual companion flag --disable-gpu is deliberately not added. It removes WebGL entirely, and a browser with no WebGL is a louder signal than a browser with no window.

A headless launch is handed exactly one address. Chromium answers that multiple targets are not supported in headless mode and exits with code 13. A live measurement on 29 August found that headless had never actually started once, and that the app was quietly falling back to the built in engine. The remaining addresses now open as tabs once the browser is up. On the built in engine, hiding means the window is created and never shown, which is not Chromium headless mode.

Hiding the window helps when nobody needs to watch. It hurts the moment something needs a person. You cannot clear a checkpoint you cannot see.

Keep the window for the first sign in to an account, and for anything that can raise a code, a captcha or a verification step. Keep it while you are still building a flow as well, because watching one run teaches more than reading the log of it afterwards.

Hiding also saves less than people expect. A hidden browser still holds its memory and still counts against the open profile limit, which ARMANOS works out from the machine's RAM. On eight gigabytes that ceiling is low, and a scheduled run waits for a free slot instead of failing the profile outright.

• First login

  Codes, captchas and checkpoints need a person and a visible page.

• While building a flow

  Run it once with a window before you put it on a timer.

• When you may want to step in

  Stop works on a hidden profile, but there is nothing inside it to click.

• As a disguise

  It removes the window, not the signals. The fingerprint still does that work.