DEV Community: Edgelog

Trading metrics look simple until you hit these 6 edge cases

Edgelog — Sat, 07 Nov 2026 10:01:00 +0000

Win rate is wins divided by trades. Profit factor is money won divided by money lost. You can write both in five minutes.

Then real trade history shows up: fees, trades that close at exactly zero, accounts that never lost, deposits in the middle of a run. We build Edgelog, a free trading journal, and these are the six cases that changed our formulas the most. If you ever build anything that summarizes trades (or any wins and losses), they apply to you too.

1. Decide what "net" means before anything else

A broker gives you a profit number and a fee number. If you classify wins on the gross number, a trade that made $10 and paid $12 in fees counts as a win. Your trader lost $2.

We compute everything on one value:

const tradeNet = (t: { pnl: number; fees: number }) => t.pnl - t.fees; // fees are a positive cost

Win, loss, totals, averages: all from tradeNet. One definition, used everywhere, beats a "gross" and a "net" version that slowly drift apart.

2. Zero is its own outcome (and floats make zero hard)

Some trades close at exactly breakeven. If you count them as losses, you punish the trader for a scratch. If you count them as wins, you flatter them.

So there are three outcomes, and the comparison happens on cents, not raw floats:

function outcome(net: number): 'win' | 'loss' | 'breakeven' {
  const cents = Math.sign(net) * Math.round(Math.abs(net) * 100); // half away from zero
  return cents > 0 ? 'win' : cents < 0 ? 'loss' : 'breakeven';
}

Without the rounding, 0.1 + 0.2 - 0.3 is a tiny positive number and becomes a "win".

Breakeven trades are left out of win rate (wins / (wins + losses)), but they stay in the trade count and in expectancy, because they still happened.

3. Profit factor with no losing trades is not infinity

Profit factor is gross profit divided by gross loss. A new account with five winning trades has a gross loss of 0, and x / 0 in JavaScript is Infinity. Show that on a dashboard and people screenshot it.

We return null and render "—" with a short note ("No losing trades yet"). With losers but no winners, it's a real 0. Typing it as number | null forces every screen to handle the empty case on purpose.

4. Expectancy should divide by every trade

Expectancy answers "what does one trade earn me on average?" We use net P&L divided by total trades, breakevens included. Dropping breakevens from the denominator makes the number look better than the trader's real experience.

5. Drawdown needs a starting point, and a choice

Max drawdown is the biggest fall from a peak. Two details matter:

The first peak is the starting balance, not the first trade. Otherwise a losing first week shows no drawdown at all.
Percent drawdown is ambiguous. The largest dollar drop and the largest percentage drop can happen at different times. We report the percentage at the point of the largest absolute drop, and we documented that choice so nobody "fixes" it into a different number later.

6. Deposits are not profit

Synced accounts often start with a small first deposit, then more money arrives later. If you measure gain against that first deposit, a modest month can show a gain of several hundred percent.

For synced accounts we use net deposits as the base: current balance minus the net P&L of closed trades. Starting balance plus every trade's net then lands exactly on the broker's balance, which is a nice built-in check.

One more thing: write the definitions down

Every one of these was a bug report before it was a rule. What helped most wasn't clever code. It was keeping a plain document that says, for each metric, the exact formula, what happens with empty input, and which edge cases are deliberate. Tests point at that document, and so do code reviews.

If you want to see these numbers on your own trades, Edgelog is free (1 connected account, up to 10,000 stored trades) and syncs MT4/MT5, Binance, Bybit and OKX read-only, or imports a CSV.

Which metric gave you the most trouble? Share the edge case you hit.

Trading involves risk. Edgelog is a journal, not financial advice.

Syncing MetaTrader trades to a web app: 5 bugs that taught us idempotency

Edgelog — Fri, 06 Nov 2026 20:25:58 +0000

We build Edgelog, a free trading journal for forex and crypto traders. The feature people care about most is the boring one: you install a small Expert Advisor in MT4 or MT5, and your closed trades show up in the journal without copying anything by hand.

It sounds simple. A script reads closed deals and POSTs them to an API. In practice it took us a lot of versions to get it right, and almost every bug came back to the same lesson: assume every message can arrive twice, late, or never.

Here are the five that hurt the most.

1. "Send each trade once" is not a strategy

Our first version sent a deal when MetaTrader told us a trade had closed, and remembered that it had sent it. Then terminals restarted, VPSs lost their connection for an hour, and the same deal got sent again from a fresh session. Or it didn't get sent at all.

The fix was to stop trying to send things exactly once and make sending twice harmless. Every deal has a ticket number from the broker, so the server stores deals in a ledger keyed by (account, platform, ticket) and upserts:

// simplified
await db
  .from('live_deals')
  .upsert(dealRows, { onConflict: 'account,platform,ticket' });

Now a replay updates a row instead of creating a duplicate trade. Closed trades are rebuilt from that ledger, so the journal is always derived from the same source of truth.

2. Events are hints, history is the truth

MetaTrader gives you trade events, but you can't rely on getting all of them. If the terminal is busy, offline, or your EA is stuck in a slow network call, a close can slip past.

So the EA now runs a reconciliation sweep every cycle. Instead of trusting what it heard, it re-reads the deal history for the window and works out what the server hasn't accepted yet. Events just make the sweep happen sooner. Because the server side is idempotent (bug #1), the sweep can be pessimistic and re-send without causing harm.

3. The broker's clock is not your clock

To read history you ask MetaTrader for deals between two times. We used the terminal's last known server time as the upper bound. That value only updates when a price tick arrives. On a quiet market, or a weekend, it goes stale, and a deal that closed after the last tick falls outside the window. It was simply invisible to the sweep.

The lesson: when you query a time window on someone else's clock, leave a margin and don't assume that clock is current.

4. "2.9" is greater than "2.10" (if you compare strings)

We show a banner when someone runs an outdated EA. It never fired. The current version was stored as a string from an older versioning scheme, and real versions like 2.10, 2.26 and 2.36 were compared as text. As strings, "2.9" > "2.10". So nobody was ever "outdated".

That mattered, because an old EA build was retrying too aggressively and burning serverless CPU. The fix was a boring numeric compare:

export function isEaVersionOutdated(installed: string, current: string): boolean {
  const parse = (v: string) => v.split('.').map((p) => parseInt(p, 10) || 0);
  const a = parse(installed);
  const b = parse(current);
  for (let i = 0; i < Math.max(a.length, b.length); i++) {
    const x = a[i] ?? 0;
    const y = b[i] ?? 0;
    if (x !== y) return x < y;
  }
  return false;
}

We also learned to bump the "minimum version" only after the compiled .ex4/.ex5 is published. Raise it first, and every installed EA gets rejected while the download link still serves the old build. That's a full outage with no way out for users.

5. A quiet market should mean a quiet server

Forex closes for the weekend, but terminals keep running. An EA polling every few seconds, multiplied by every user, is a lot of pointless requests on a serverless bill.

Two changes fixed most of it. The server acknowledges heartbeat-style posts before doing any database work. And the EA backs its timer off when nothing is happening, then speeds up again on the next trade. We set the backoff once when entering idle, not on every tick, which was its own small bug.

The part we didn't compromise on: read-only

The EA only reads account and deal history. It never places, modifies or closes orders. For a journal that felt like the right line: traders are trusting it on a live account, and a sync tool should not be able to trade.

Crypto works the same way. Binance, Bybit and OKX connect with read-only API keys.

If you want to try it

Edgelog is free: one connected account and up to 10,000 stored trades, plus CSV import if you don't use MetaTrader. You get a journal, a playbook for your setups, and stats like win rate, profit factor and drawdown by session.

👉 edgelogtrading.com

If you've built sync for a desktop app that drops connections, we'd like to hear how you handled it. Idempotency keys, sweeps, something else?

Trading involves risk. Edgelog is a journal, not financial advice.