Most people find the live page and stop there, then ask us whether something happened last Tuesday. Massive publishes two pages, and the second one answers that: it keeps the incident record, breaks uptime down by asset class and by REST, WebSocket and flat files separately, and lets you subscribe so an incident reaches you instead of you going to look.
Applies to
- Plans: all plans. Neither page needs an account or a key.
- Endpoints: between them they cover the REST API, the WebSocket clusters and the flat files, for every asset class.
- Asset classes: all.
Which page answers which question
Which page answers which question comes down to tense: now, or then. Both link to each other, so either is a fine place to start:
| The question | Where to look |
|---|---|
| Is something broken right now? | massive.com/system |
| Was there an incident on a particular day? | massive-status.com |
| What has uptime been over the last 90 days? | massive-status.com |
| Tell me when something breaks | Subscribe on massive-status.com |
| Are the exchanges open right now? | /v1/marketstatus/now |
| Is tomorrow a market holiday? | /v1/marketstatus/upcoming |
massive.com/system is the live view, and it links onward to the other page as the "system monitoring app". The link back is to the Massive home page rather than to /system, so keep both bookmarked rather than expecting to hop between them.
How the incident page is broken down
The incident page is broken down by asset class rather than by service, which is what makes a partial outage readable. Stocks, Options, Indices, Forex and Crypto each carry four components:
- Market Data REST Endpoints
- Reference Data REST Endpoints
- Market Data WebSocket Channels
- Market Data Flat Files
Futures carries three, named Futures REST Endpoints, Futures WebSocket Channels and Futures Flat Files, with no separate reference-data line. So "REST is fine but the WebSocket is degraded, on options only" is a state the page can actually show, and that is usually the shape of a real incident.
How to subscribe
Subscribe rather than poll. The incident page offers four routes, and all of them are on the Subscribe control at the top of massive-status.com:
- Email, confirmed with a one-time code.
- SMS, by country code and number.
- Slack, which posts incident and maintenance updates into a channel you choose.
- Atom or RSS, if you would rather your own tooling read it.
A support chat that opens with "we saw the incident notice, is this the same thing?" is a much shorter conversation than one that starts from a screenshot of a failed request.
Why there are two pages
There are two pages because "is it broken now" and "what happened and when" are different questions with different shapes. The live page runs continuous checks and has to answer in one glance, so it shows the current state and nothing else. The incident page is a record: humans write the updates, it keeps them, and it can tell you afterwards. Merging them would make the live view slower to read and the history harder to trust.
If you see an error
A 5xx response or a connection reset, with both pages green, is worth reporting. Start a chat at massive.com/contact with the request_id from the response body, because that is what lets us find the request in our own logs.
A 401, 403 or 429 is never an outage. Those are answers about your key and your plan.
An empty results array with HTTP 200 is a data question, not a service question. The market was probably closed for the range you asked about: a quiet feed at 03:00 is a closed market, and both status pages will correctly show everything healthy.
