# Uptime

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

Source: https://tickwire.io/docs/uptime/

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:

| Kind | Meaning |
|---|---|
| Connected | The terminal reported a working connection to the broker |
| Down | The account was deployed but not connected: disconnected, in error, or reconnecting |
| No data | We were not checking at that moment, or the status was unknown |

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:

| Side | What it covers |
|---|---|
| Tickwire side | Our servers or software: a terminal we could not reach, read or start |
| Broker side | The broker or the account's login: the broker server dropped the link, or rejected the login |
| Unknown | The record does not say which side it was |

**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):

| Colour | Meaning |
|---|---|
| Green | Measured, no downtime |
| Amber | Some downtime, 95 % or more available |
| Red | Under 95 % available |
| Grey | No data |

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

## From the API

```bash
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.

```json
{
  "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.

| What happened | Alert after |
|---|---|
| A server that runs terminals is shutting down | 2 seconds |
| A server that runs terminals stops answering | 20 seconds |
| A terminal lost its connection because of our side | 30 seconds |
| A terminal is connected but its prices stopped moving | 60 seconds |
| The broker dropped or refused the connection | 2 minutes |
| A server misses its check-ins but still answers directly | 60 seconds, marked "state unknown" |
| The cause is not known | 5 minutes |

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](https://tickwire.io/docs/webhooks)).