How to Check if Google Workspace, GitHub, Cloudflare, Slack, or OpenAI Is Down

When a tool stops working, the fastest reliable way to check whether Google Workspace, GitHub, Cloudflare, Slack, or OpenAI is down is to read each vendor's official status page and compare it with what your own users are seeing. The official page is the authoritative source for what the vendor is reporting. A third-party "is it down" aggregator can hint at trouble, but it cannot confirm what the provider is actually saying.

This is a method, not a live status report. This article does not tell you whether any of these services is up or down right now — it shows you how to check, in a repeatable order, and how to avoid the trap of assuming a vendor's status equals your own.

Fast Answer Checklist

When something breaks, work through this in order:

1. Open the vendor's official status page (links below) and read the current state and any open incident.
2. Compare with internal symptoms — does what the vendor reports match what your users actually experience?
3. Check your own DNS, domain, certificate, and email-authentication systems to rule out a local cause that looks like a vendor outage.
4. Document what you saw and when, so the post-incident review and any client update are grounded in facts.

If the official page reports an incident that matches your symptoms, you have likely found the cause. If it does not, the problem may be local, regional, or tenant-specific — keep investigating before blaming the vendor.

Step 1: Check Official Vendor Status Pages

Always start at the source the vendor controls. These are the official status pages for the example vendors:

• Google Workspace — Google Workspace Status Dashboard
• GitHub — GitHub Status
• Cloudflare — Cloudflare Status
• Slack — Slack Status
• OpenAI — OpenAI Status

On each page, read three things: the overall state (operational vs degraded vs outage), any open incident's description and severity, and the timestamp of the latest update. Note that a status page reflects the vendor's decision to publish — it can lag a brand-new issue, and it describes the provider's platform overall rather than your specific account.

To avoid checking these one tab at a time, CertPilot's free Vendor Status Checker caches the official, vendor-reported status for supported providers in one normalized view, including per-vendor pages for Google Workspace, GitHub, Cloudflare, Slack, and OpenAI. It mirrors what those vendors publish; it does not add its own up/down verdict.

Step 2: Compare With Internal Symptoms

A status page is only half the picture. The other half is what your users are actually reporting. Line them up:

• What broke, exactly? "Login fails," "pushes time out," "messages won't send," "API returns errors." Specific symptoms match incidents better than "it's slow."
• Who is affected? Everyone, one region, one team, or one person? Broad impact is more consistent with a vendor incident; a single user often points to something local.
• When did it start? Compare your first report against the incident's opened-at time. A close match strengthens the link; a mismatch weakens it.
• Does the vendor's wording fit? A vendor incident about a feature you do not use is probably not your problem.

A loose match is a clue, not proof. Resist the urge to declare "it's the vendor" until the symptoms and timing genuinely line up.

Step 3: Check Your Own DNS, Domain, Email, and Auth Systems Where Relevant

Many "the vendor is down" incidents turn out to be local. Before you escalate to a provider, rule out causes you control:

• DNS: a recent record change, a propagation delay, or a misconfigured entry can break connectivity to a service that is itself perfectly healthy.
• Domain and certificate: an expired domain or an expired/misissued TLS certificate produces failures that feel like an outage but originate on your side.
• Email authentication: if "email is broken," check SPF, DKIM, DMARC, and related records before concluding the mail provider is down.
• Recent changes: a config push, firewall rule, or key rotation in the last hour is a prime suspect.

CertPilot checks several of these public-facing facts directly — SSL/TLS, DNS, domain registration, and email-authentication records on the domains you manage — through External Footprint Monitoring. Confirming your own footprint is clean lets you say "it's the vendor" with far more confidence.

Step 4: Document What Happened

Whether the cause is the vendor or your own environment, write it down while it is fresh:

• Which vendor and which official page you checked, and the state it showed.
• The incident title, severity, and key timestamps the vendor published.
• The symptoms your users reported and when.
• What you checked on your own side and what you found.
• When the vendor marked it resolved, and when you confirmed recovery.

This record turns a stressful hour into reusable evidence — useful for a post-incident review, a client update, or simply remembering what happened next time. CertPilot's platform is built around turning this kind of operational record into management-ready evidence, though it captures vendor status as reported context, not as a tenant-impact claim.

Why Vendor Status Does Not Always Equal Tenant Impact

This is the point most "is it down?" checks miss. A vendor status page describes the provider's platform overall — it does not measure your specific tenant.

• A vendor can show "all systems operational" while your single account hits a localized issue the vendor has not flagged.
• A vendor can report a regional or component incident that never reaches you, because you sit elsewhere or do not use the affected feature.
• A status page updates on the vendor's schedule, so a real problem can exist before it appears — or linger in your environment after the vendor marks it resolved.

So "GitHub reports an incident" is not the same as "our builds are failing because of GitHub," and "Cloudflare is operational" is not proof your site is reachable. Always confirm tenant impact with your own observations rather than reading it off a global page. That is also why CertPilot reports vendor-reported status only and does not claim tenant-specific impact.

How CertPilot Helps Centralize This

Checking five status pages by hand during an incident is exactly when you have the least time to do it. CertPilot's Vendor Status Watch centralizes the first step:

• It reads official public vendor feeds and caches each provider's reported status server-side, normalized into one view.
• It refreshes on a daily schedule by default, with a manual "Refresh now" inside the logged-in dashboard; the public checker is read-only with no refresh button.
• Your workspace keeps a watchlist of the vendors your team actually depends on, so the board reflects your stack.

What it deliberately does not do: it uses no customer credentials, runs no synthetic uptime probes, validates no SLAs, automates no incident response, and never claims your tenant is affected. It mirrors what vendors publish — the rest of the method (matching symptoms, checking your own systems, documenting) stays in your hands.

Make the Check Repeatable

The goal is a routine you can run in minutes without depending on memory. Start at the official pages, compare against real symptoms, rule out your own DNS/domain/email/auth, and write it down. To skip the tab-juggling, open the free Vendor Status Checker for cached vendor-reported status, and create a workspace to track the vendors your team depends on so the check is one click instead of ten — while keeping the boundary clear between what a vendor reports and what your tenant actually experiences.

Frequently Asked Questions

What is the most reliable way to check if a service is down?

Read the vendor's own official status page first, then compare it with what your users are actually experiencing. The official page is authoritative for what the vendor is reporting, while your internal symptoms tell you whether your specific environment is affected.

Does a green status page mean my account is fine?

No. A green or "operational" status page only means the vendor has not published an incident. Your account can still hit a localized, regional, or tenant-specific issue the vendor has not flagged. Always confirm with your own observations.

Does CertPilot tell me whether these services are down right now?

CertPilot mirrors what each vendor publishes on its official status feed, cached and refreshed on a daily schedule. It does not add its own up/down verdict, run synthetic uptime probes, or claim that your specific tenant is affected. For the live picture, also read the vendor's official page directly.

Why check my own DNS, domain, and email systems during an outage?

Because many apparent vendor outages are actually local. An expired certificate, a DNS change, or a broken email-authentication record can produce symptoms that look exactly like a provider being down. Ruling these out first prevents wasted escalation.

Which vendors does CertPilot's Vendor Status Watch cover?

CertPilot supports a fixed, curated list of vendors read from their official public status feeds — Google Workspace, GitHub, Cloudflare, Slack, and OpenAI are examples. The free Vendor Status Checker shows the current supported set with per-vendor pages.