What does ac=n/d mean in an Autoview alert?

ac takes a fraction, like ac=2/3. The numerator n is the step this alert represents, the denominator d is how many steps the sequence has. The command only trades once the final step arrives in order; earlier steps advance the counter and stop before anything trades. This is enforced on the Chrome extension; see below for the cloud webhook platform.

What does acg do, and why does the name matter?

acg names the counter a step belongs to, so two unrelated alert sequences never interfere with each other as long as they use different names. Reuse the same acg across unrelated alerts and their steps collide in one shared counter, so an out-of-order arrival from one sequence breaks the other. acg never does anything on its own -- it only matters together with ac.

What happens if an ac step arrives out of order?

The sequence is broken. If the incoming n is not exactly one more than the last step the counter accepted, Autoview resets that counter to 0 and the command stops without trading. The log shows a reset line, and the sequence has to restart cleanly from step 1 to trade again.

Does a bare ac value like ac=3 count as step three?

No. Without a slash, ac collapses to 1/1, a complete one-step sequence, not step three of anything. To track an ordered sequence you must write the fraction out, like ac=3/4. A bare value with no slash accepts step 1 immediately and trades at once, rarely what a counter is meant to do.

Does ac/acg work on the cloud webhook platform?

No, not today. The cloud webhook platform accepts ac and acg without an error, but no code path on that platform stores a counter, checks the sequence, or stops a command. A command sent straight to a webhook trades immediately regardless of ac, exactly as if ac and acg were never written. ac/acg only function on the Chrome extension.

Alert counting and grouping: the ac and acg parameters

Autoview · Alert syntax · Updated July 11, 2026

ac and acg are a pair. Together they let a command stay quiet until a run of alerts arrives in the right order, and only then act. ac is the step number, written as a fraction like 2/3. acg is the name of the counter that step belongs to. You send a series of alerts that walk through the steps, and the command on the last step is the one that actually trades.

This only works on the Chrome extension today. The extension stores the counter per acg name and gates the rest of the command on it, exactly as described below. The cloud webhook platform parses ac and acg without error but does not act on either: no counter is stored, no sequence is checked, and the command runs immediately every time regardless of the step it claims to be. If your alerts go straight to a webhook, not through the extension, every step trades on its own, silently, not just the final one. This is confirmed against the source, not inferred; see "What is certain, and what is not" below.

Here is the shape of it:

ac=3/3 acg=breakout e=oanda s=EUR_USD b=long q=2%

On its own that line says: this is step 3 of 3 in a counter named breakout, and if the counter has already seen steps 1 and 2 in order, place the order. If it has not, do nothing and reset.

The rule: ac=n/d and acg=name

ac takes a fraction, n/d. The n is which step this alert is, the d is how many steps the sequence has. acg takes a plain name. That name is the counter the steps are tracked against, so two unrelated sequences using different names never interfere with each other.

Three things about the fraction:

It is written with a slash. ac=2/3 is step two of a three-step run. The numerator is the position, the denominator is the length.
A bare number is not a step count. If you write ac=3 with no slash, it does not mean step three. With no slash the value collapses to 1/1, a single-step sequence. To count steps you must write the fraction out.
Both parts are at least 1. A zero or a missing part is treated as 1.

What it actually counts

Each counter, named by acg, remembers the last step it accepted. When an alert with an ac arrives, Autoview checks whether its n is the next step in line:

If n is 1, the counter starts fresh at 1.
If n is exactly one more than the step the counter last accepted, the counter advances to n.
If n is anything else, the sequence is broken. The counter resets to 0 and this command stops without trading.

So the counter is not a "fire every Nth alert" tally. It is an ordered-sequence tracker. It only moves forward when the steps arrive in order, 1 then 2 then 3, each as its own alert pointing at the same acg name.

When the command actually runs

Reaching a step is not the same as acting on it. The command on a given step runs the rest of its line only when both of these are true:

The counter accepted the step, so the result is not 0 (the sequence is still intact), and
the step is the final one, meaning n is greater than or equal to d. That is what the code calls an improper fraction.

On every earlier step, the counter advances and logs its progress, but the command stops before trading. Only the last step, where n reaches d, lets the rest of the command through. And if any step arrives out of order, the counter resets to 0 and that command stops too.

A worked example

Three alerts, each its own TradingView alert, all pointed at a counter named confirm:

// alert 1 fires
ac=1/3 acg=confirm e=oanda s=EUR_USD b=long q=2%

// alert 2 fires
ac=2/3 acg=confirm e=oanda s=EUR_USD b=long q=2%

// alert 3 fires
ac=3/3 acg=confirm e=oanda s=EUR_USD b=long q=2%

Walk it through. Alert 1 sets the confirm counter to step 1 and stops, no order. Alert 2 advances it to step 2 and stops, no order. Alert 3 is step 3 of 3, the final step, so once it advances the counter the rest of the line runs and the long is placed. You needed all three confirmations, in order, before a single trade went out.

If alert 2 never arrives and alert 3 comes next, step 3 is not one more than step 1, so the counter resets to 0 and alert 3 does nothing. The sequence has to be clean.

What the log shows

Each time an ac command runs, Autoview logs the counter by name and the step it reached, like Alert Count (confirm): 2 / 3. When a step arrives out of order and the counter resets, the log reads Alert Count (confirm): reset instead. That line is how you see, after the fact, how far a sequence got and whether it completed or broke.

Why the group name matters

The acg name is what keeps independent sequences apart. Two strategies can both use a three-step confirmation at the same time, and as long as they use different acg names their counters never touch. Reuse the same name across unrelated alerts, though, and their steps will collide in one shared counter, so an out-of-order arrival from one breaks the other. Pick a name per sequence and keep it unique to that sequence.

Things worth knowing

One alert is one step. The counter advances per alert received, not within a single multi-line alert. The sequence is built across separate alerts that share an acg name.
Order is strict. Steps must arrive 1, 2, 3 with no gaps and no repeats. A skipped or duplicated step resets the counter to 0.
Only the last step trades. Earlier steps advance the counter and stop. Put the action you want gated on the final step, where n equals d.
A bare value runs immediately. ac=1/1, or any ac with no slash, is a complete one-step sequence, so it accepts step 1 and runs at once. That is rarely what you want from a counter.
It only runs on the Chrome extension. Everything above is accurate for the extension. On the cloud webhook platform, ac and acg are accepted and ignored: both parse cleanly, but nothing stores a counter or checks a sequence, so every step trades immediately on its own.
acg does nothing by itself. The counter name is only ever consulted as part of handling ac. Setting acg on a command that has no ac has no effect at all.

What is certain, and what is not

Certain from the code: on the Chrome extension, ac takes an n/d fraction and acg takes a plain name; the counter named by acg advances to n only when n is 1 or exactly one more than the last accepted step, and resets to 0 otherwise; and the rest of the command runs only when the counter is non-zero and n is greater than or equal to d.

Also certain from the code, and the reason this page carries a warning above: on the cloud webhook platform, the same ac/acg parameters are parsed into the command object and then never read again anywhere in that platform's integration code -- across all 33 primary exchange/broker integration files plus the shared parser and dispatch code, there is no counter, no sequence check, and no log line. A command carrying ac=1/3 sent straight to a webhook trades exactly as if ac and acg were never written. The stand-alone runner has the same gating logic present in its source but explicitly disabled, throwing an error rather than running it, so it behaves like the cloud webhook platform in practice: nothing is gated.

Unknown from the code alone: exactly how long a stored counter persists on the extension, and how it behaves across a browser restart or a very long gap between steps. If a sequence needs to survive that reliably, test it against your own alerts rather than assuming.

For everything the order lines themselves can do, side, sizing, stops, order type and the rest, see the command reference, or the full alert syntax page.

Read the command reference