Uptime

How Tickwire measures each account's availability, what counts as down, and whose side an outage was on.

Every account has an uptime figure for the last 24 hours, 7 days and 30 days. You can see it on the account’s page in the dashboard and read it from the API. It is measured from what we recorded, not estimated. When we did not record enough, we say so instead of showing 100 %.

What we measure

We check every running terminal about every 15 seconds and record each change of status, with the reason. We also record, once a minute, that this checking was running. Uptime is built from those two records.

Only time when the account was meant to run counts. That is time when the account was deployed, after it first connected. Each counted second is one of three things:

These are never counted:

• Setup. The time from each deploy until the account connects. A wrong password or server shows up as a setup problem on the account page, not as downtime.
• Undeployed or parked time. If you stop an account, that time is left out.
• No data. It is never counted as up, and never as down.

The numbers

Availability is connected time divided by connected plus down time, as a percentage with up to three decimals.

It is null until at least one hour has been measured, or 5 % of the period, whichever is smaller. The dashboard shows “Not enough data yet” in that case. A new account therefore shows no number for its first hour.

Each outage is put on one side, from the reason we recorded:

Tickwire-side availability counts only Tickwire-side downtime as down, and leaves the other downtime out. It is the figure that shows how well we ran your terminal, whatever your broker did.

An outage is one unbroken run of down time. It ends when the account connects again or is undeployed. Short gaps with no data inside an outage do not end it. Its side is the side with the most down time in it. Mean time to recover is the average length of the outages that have ended.

On the dashboard

The account page has an Uptime card above the health history. It shows:

• availability for 24 hours, 7 days and 30 days, each with the Tickwire-side figure;
• the number of outages in 30 days, and the longest one;
• one bar per day for the last 30 days (UTC days):

Each row of the health history also says which side a change was on.

From the API

curl -s "https://api.tickwire.io/users/current/accounts/acc_7Qx/uptime?days=30" \
  -H "auth-token: $TW_KEY"

days sets the window for outages and daily, from 1 to 90 (default 30). The three periods are always the last 24 hours, 7 days and 30 days.

{
  "accountId": "acc_7Qx",
  "generatedAt": "2026-10-20T12:00:00Z",
  "days": 30,
  "windowStart": "2026-09-20T12:00:00Z",
  "windowEnd": "2026-10-20T12:00:00Z",
  "availabilityPercent": 99.942,
  "tickwireAvailabilityPercent": 99.988,
  "connectedSeconds": 2589000.0,
  "downSeconds": 1500.0,
  "downSecondsByCause": { "tickwire": 300.0, "broker": 1200.0, "unknown": 0.0 },
  "noDataSeconds": 0.0,
  "outageCount": 2,
  "mttrSeconds": 750.0,
  "periods": {
    "last24Hours": { "availabilityPercent": 100.0, "...": "same fields as above" },
    "last7Days": { "availabilityPercent": 99.802, "...": "same fields as above" },
    "last30Days": { "availabilityPercent": 99.942, "...": "same fields as above" }
  },
  "longestOutage": {
    "start": "2026-10-15T22:01:10Z",
    "end": "2026-10-15T22:21:10Z",
    "ongoing": false,
    "durationSeconds": 1200.0,
    "downSeconds": 1200.0,
    "cause": "broker",
    "downSecondsByCause": { "tickwire": 0.0, "broker": 1200.0, "unknown": 0.0 },
    "reasons": ["no broker connection"]
  },
  "outages": [],
  "outagesTruncated": false,
  "daily": [
    { "date": "2026-10-20", "availabilityPercent": 100.0, "level": "up",
      "connectedSeconds": 43200.0, "downSeconds": 0.0,
      "downSecondsByCause": { "tickwire": 0.0, "broker": 0.0, "unknown": 0.0 },
      "noDataSeconds": 0.0 }
  ]
}

• availabilityPercent and tickwireAvailabilityPercent are null when too little was measured. Treat null as “not known”, never as 100.
• outages is newest first, at most 100. outagesTruncated is true when there were more.
• An ongoing outage has end: null and ongoing: true. Its duration runs to generatedAt.
• durationSeconds can be longer than downSeconds when part of the outage had no data.
• daily is oldest first, one entry per UTC day. level is up, partial, down or noData.
• All times are ISO-8601 UTC.

The endpoint needs an API key, or a token with read access to accounts. Another organisation’s account returns 404.

Alerts

Our on-call team is alerted when something stays wrong for longer than the time below. Our own failures page fast. Broker-side problems wait longer, because brokers restart servers and go quiet at weekends.

Each server checks in every 5 seconds. Three missed check-ins make it suspect, and we then test it directly before anyone is paged. If the evidence disagrees, the alert says “state unknown”, not “down”. One problem sends one alert, and one more message when it ends, with how long it lasted. When a whole server is affected, its accounts are covered by that one alert instead of one alert each. All of this works the same for MT4 and MT5 accounts.

The public status page shows a “Trading servers” outage once one of our servers has been down for 60 seconds.

To be told yourself, subscribe to account events (see Webhooks).