All services

Is X down?

X is up.

OperationalChecked moments ago from N. Virginia · responded in 101 ms

Our last check reached x.com and got a healthy response.

Last 30 days

The numbers

Availability and response time for X over the last 24 hours.

Availability

100%

144 checks, none failed

Avg response

283 ms

Mean of every check

Slowest

2.75 s

Worst single check

Incidents

0

Runs of failing checks

Downtime

None

Estimated from samples

Downtime is estimated from 10-minute samples, so figures are accurate to within one check interval.

Over time

Every check we ran, and how long each one took.

Availability

05:30Each bar is 10 minutesnow
  • All checks passed
  • Some checks failed
  • All checks failed

Response time

Where the time goes

"Is it down?" is usually really "it feels broken — what's wrong with it?" This is the answer: every millisecond of a request to x.com, broken into the four phases it actually spends time in.

DNS

Resolving the hostname to an IP address.

2 ms1%
TCP + TLS

Opening the connection and completing the TLS handshake.

18 ms6%
Time to first byte

Waiting for the server to start responding. Usually the server thinking.

251 ms89%
Download

Transferring the response body.

12 ms4%

Averaged over the last 24 hours. The four phases add up to the total response time of 283 ms.

Incidents

Every time a check against x.com failed in the last 30 days, grouped into incidents.

No incidents recorded for X.

Every check we’ve run against X has passed.

This page is a Checkly monitor.

Not a mockup of one. Everything above is produced by the monitor below, running every 10 minutes from N. Virginia and Frankfurt. It lives in a repo, gets code-reviewed, and deploys from CI — the same way you would monitor your own service.

That’s the whole product. Monitoring you can read, diff, and version.

availability-x.check.ts
1import {
2 UrlMonitor,
3 UrlAssertionBuilder,
4 Frequency,
5 RetryStrategyBuilder,
6} from 'checkly/constructs'
7
8new UrlMonitor('availability-x', {
9 name: 'X (x.com)',
10 activated: true,
11 frequency: Frequency.EVERY_10M,
12 locations: ['us-east-1', 'eu-central-1'],
13 degradedResponseTime: 3000,
14 maxResponseTime: 10000,
15 // Confirm before we call it down: retry a failure from the other
16 // region, so a transient blip never gets published as an outage.
17 retryStrategy: RetryStrategyBuilder.exponentialStrategy({
18 baseBackoffSeconds: 5,
19 maxRetries: 2,
20 sameRegion: false,
21 }),
22 request: {
23 url: 'https://x.com',
24 followRedirects: true,
25 skipSSL: false,
26 assertions: [
27 UrlAssertionBuilder.statusCode().lessThan(400),
28 ],
29 },
30})
Monitor your own serviceHow uptime monitoring works

How we check X

A real request to the endpoint that matters, every 10 minutes — measured, not crowd-sourced.

What we actually do

  • We send a real HTTP GET to https://x.com every 10 minutes.
  • We run it from two datacenters: N. Virginia and Frankfurt.
  • It passes if the endpoint answers with a status below 400 within 10 seconds. Slower than 3 seconds is “degraded”, not down.
  • A single failed check isn’t a verdict. We retry it from the other region before recording anything, so a transient blip never shows here as an outage.

What a green check means

  • X answered a real request from both N. Virginia and Frankfurt — an actual measurement, not complaints counted from a crowd.
  • We probe the endpoint that fails when X fails, so a green check tracks the part you depend on, not a marketing page that stays up regardless.
  • Checks run around the clock, every 10 minutes, on the same infrastructure Checkly customers monitor production with.

Frequently asked

No. Our most recent check reached https://x.com and got a healthy response. We check every 10 minutes from N. Virginia and Frankfurt.

We run a real HTTP request against https://x.com every 10 minutes from N. Virginia and Frankfurt, using Checkly's synthetic monitoring. A check passes when the endpoint returns a status below 400 within 10 seconds. We are not counting user reports — we are measuring the actual response.

We probe https://x.com because it is the endpoint that best reflects whether X is actually usable.

We check X from N. Virginia and Frankfurt. If it answers us but not you, the problem is usually specific to your network, ISP, region, or account rather than X itself.

Downdetector counts user reports — how many people are complaining. We run an actual synthetic check against the service and report what the wire says. Reports lag the outage and can be noisy; a probe either gets a response or it doesn't.

See every service we monitor