These are measured numbers, not a marketing range. Every tweet Xanguard delivers is timed from the moment X says it was posted to the moment it first reaches our servers. This page publishes the result for all paid-plan accounts and refreshes every hour. Last update: 12 Oct 2026 06:00 UTC.
Tweet detection latency, paid plans
| Window | Tweets measured | p25 | Median (p50) | p90 | p95 | p99 |
|---|---|---|---|---|---|---|
| Last 24 hours | 22,113 | 177 ms | 209 ms | 464 ms | 596 ms | 877 ms |
| Last 7 days (05 Oct 2026 to 12 Oct 2026) | 181,724 | 174 ms | 206 ms | 510 ms | 629 ms | 14864 ms |
| Share of tweets detected | Last 24 hours | Last 7 days |
|---|---|---|
| In under 500 ms | 91.3% | 89.6% |
| In under 1 second | 99.2% | 97.9% |
Uptime, measured
Method: Xanguard counts as up when it detects at least one paid-plan tweet alert in every 5-minute window; any silence of 5 minutes or more counts as downtime for its full length. It is measured from the same production data as the latency above, not from a ping.
| Window | Uptime | Incidents (5+ min) |
|---|---|---|
| Last 30 days | 100% | 0 |
| Last 90 days | 99.99% | 1 |
Longest silence in 90 days: 5.8 minutes. Last incident: 04 Sep 2026 00:30 UTC. Restarts for updates usually cost under a minute of detection and are counted if they ever reach 5 minutes. These are past measurements, not a service level agreement.
How we measure
- Start of the clock: the creation time X embeds in every tweet ID, to the millisecond.
- End of the clock: the first moment that tweet arrives on a Xanguard server.
- Sample: every tweet delivered for accounts tracked on paid plans (Tweet Alerts and the B2B API). Nothing is hand-picked, and we publish p95 and p99, not only the best case.
- Excluded: arrivals later than 10 minutes, which are recoveries after an outage rather than live detections. The free plan is not included because it runs on a slower cycle.
- Not included: the last hop to you. Telegram delivery adds roughly 0.3-0.4 s; end-to-end to your Telegram is about 0.6 s median. WebSocket transit depends on where your server is.
You can check this yourself. Every B2B tweet event carries created_at, the post time X embeds in the tweet ID, in milliseconds. Subtract it from the time your own client receives the event: the result is our detection time plus the network hop to you, so it should sit slightly above the figures on this page. Tweet events do not carry a separate detection timestamp; non-tweet events (deletions, follows, profile changes) carry event_time, when we detected them. The raw figures behind this page are also available as /speed.json.
Why a median and not a record
A single fastest detection says little about what you will get on a normal day. The median tells you what half of all tweets beat, and p95 and p99 tell you how bad the slow ones are. If you trade on tweets, the tail matters as much as the median, which is why all of them are on this page.
Want to check it on an account you care about? The Telegram bot tracks one account for free, and paid plans start at $19 a month for 10 accounts.
Frequently Asked Questions
Over the last 7 days, the median time from a tweet being posted to Xanguard detecting it was 206 ms on paid plans. 89.6% of tweets were detected in under 500 ms and 97.9% in under one second, measured across 181,724 tweets. The figures on this page refresh every hour from production data.
The time between the timestamp X assigns to the tweet when it is posted and the first moment that tweet reaches a Xanguard server. It covers every tweet delivered for accounts on paid plans. It does not include the final hop to your Telegram chat or WebSocket client. Telegram delivery adds roughly 0.3-0.4 s; end-to-end to your Telegram is about 0.6 s median.
No. The numbers on this page are for paid plans. The free plan uses a slower checking cycle and is meant for trying the product on one account.