All services

Is Max down?

Max is up.

OperationalChecked 6 minutes ago from Frankfurt · responded in 560 ms

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

Last 30 days

The numbers

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

Availability

96.77%

1 of 31 checks failed

Avg response

219 ms

Mean of every check

Slowest

560 ms

Worst single check

Incidents

1

Runs of failing checks

Downtime

46m

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:00Each 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 max.com, broken into the four phases it actually spends time in.

DNS

Resolving the hostname to an IP address.

15 ms7%
TCP + TLS

Opening the connection and completing the TLS handshake.

1 ms0%
Time to first byte

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

57 ms26%
Download

Transferring the response body.

146 ms67%

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

Incidents

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

Incidents observed for Max, most recent first.
Started (UTC)DurationWhat we sawLocations
Jul 15, 03:21< 10mError response

HTTP 504 504 Gateway Time-out

N. Virginia

1 failed check

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-max.check.ts
1import {
2 UrlMonitor,
3 UrlAssertionBuilder,
4 Frequency,
5} from 'checkly/constructs'
6 
7new UrlMonitor('availability-max', {
8 name: 'Max (max.com)',
9 activated: true,
10 frequency: Frequency.EVERY_10M,
11 locations: ['us-east-1', 'eu-central-1'],
12 degradedResponseTime: 3000,
13 maxResponseTime: 10000,
14 request: {
15 url: 'https://www.max.com',
16 followRedirects: true,
17 skipSSL: false,
18 assertions: [
19 UrlAssertionBuilder.statusCode().lessThan(400),
20 ],
21 },
22})

How we check Max

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://www.max.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.

What a green check means

  • Max 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 Max 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://www.max.com and got a healthy response. We check every 10 minutes from N. Virginia and Frankfurt.

We run a real HTTP request against https://www.max.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://www.max.com because it is the endpoint that best reflects whether Max is actually usable.

We check Max 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 Max 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.