What should I check on the service status page when something fails?
Check the freshness of the information, the affected service, and the latest relevant incident update. The public status page is useful context, but an operational summary does not prove that your individual bot action or Fortnite match succeeded.
Read freshness before interpreting the color
The page distinguishes current information, older received information, and unavailable data. If its last refresh failed, an earlier successful reading should not be treated as a fresh guarantee. Compare the last check and last received data times before deciding whether an incident is ongoing. A healthy service label from an old snapshot answers a different question from a current observation. When reporting a problem, note what the page actually says about freshness rather than copying only the most reassuring green indicator.
Look at the service and incident detail
Use the service and active-incident filters to find information relevant to the symptom you observed. Read the sequence of updates rather than assuming that an old resolved incident explains a new failure. Provider notices are preserved in their original language, while the surrounding interface can be translated. A public incident may help explain a wider interruption, but it does not establish the cause of every individual invitation, account-recovery, or cosmetic problem that happens near the same time.
Keep latency and availability claims bounded
The published API latency is not your player's in-game ping, and the history bars represent published incidents rather than a continuous measurement of every session. Use those charts as context alongside the exact action, time, and response from your own panel. If your bot fails while the summary is operational, report the specific failure rather than assuming your observation is invalid. If an incident is listed, follow its current update without repeatedly restarting working connections solely to see whether the summary changes color.