Is Fastly down?

Last checked 4m ago
Current status
Fastly is up

No new incidents. 1 long-running issue listed below.

  • Official status page: fastlystatus.com
  • Checked every 5 minutes
  • 257 components tracked

Fastly is operational right now, apart from 1 long-running issue open since September 22, 2026. Last checked 4m ago.

Real-time Fastly status, recent outages, and incident history: pulled directly from Fastly's official status page at fastlystatus.com every 5 minutes. Pingoru tracks 257 Fastly services and has captured 89 incidents in the last 90 days (96.45% uptime). Get email, Slack, Discord, or webhook alerts the moment Fastly reports a new incident, free for 3 monitors, no credit card.

Users who monitor Fastly also follow these CDN services: Cloudflare imgix Font Awesome Twingate cdnjs WeTransfer Teleport Iristel Jitterbit Hygraph View all 8,000+ providers
Fastly uptime 96.45% uptime · past 90 days
Mon Wed Fri
JulAugSepOct
Less More

Active incidents 3

  1. Ongoing ● 5d 9h
    Started Oct 23, 2026, 02:20 AM UTC
    API & Configuration ManagementAPI ServicesFastly Control PanelFastly Control PanelFastlyFastly Control PanelAPI & Configuration ManagementAPI ServicesFastlyFastly
    Timeline · 1 update
    • investigating · Oct 23, 2026, 02:20 AM UTC

      Recently Fastly identified an issue affecting Domainr and Domain Research API. This issue may result in non-authoritative or "unknown" domain statuses for certain top-level domains (TLDs) for our customers. What happened? Domainr verifies domain status by connecting directly to registries. Following a routine certificate rotation, the new certificate no longer includes the client authentication component that some registries require to accept these connections. This reflects a public certificate authority (CA) change that took place earlier this year. For the affected TLDs, Domainr can't verify status directly with the registry. It falls back to resellers, DNS, or WHOIS where available. In situations where none are available, the API returns an "unknown" or “non-authoritative” status. The API continues to operate normally and returns successful (200) responses. Domain status data for affected TLDs may be less accurate or incomplete. What’s next? What do I have to do? There is no workaround, and no action is required on your part. Our Engineering team has already reached out to affected registries to partner with them on supporting and installing compatible certificates. Resolution depends on both this partnership and the completion of necessary system updates by the affected registries. Fastly Support is available to answer questions you may have and provide updates if available. We sincerely apologize for not providing earlier notice. We will update this status page as we receive more information. Customers with any other questions or concerns may engage with our Support team through https://support.fastly.com or by contacting your designated account management team members.

    Latest: Recently Fastly identified an issue affecting Domainr and Domain Research API. This issue may result in non-authoritative or "unknown" domain statuses for certain top-level domains…

  2. Ongoing ● 6d 16h
    Started Oct 21, 2026, 07:26 PM UTC
    FastlyFastlyCustomer ServicesFastlyCustomer ServicesCustomer ServicesGeneral UpdatesFastlyGeneral UpdatesFastly
    Timeline · 1 update
    • investigating · Oct 21, 2026, 07:26 PM UTC

      A security disclosure regarding php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) was published on October 21, 2026. In addition to implementing certain mitigations, we published a blog post about this disclosure for all customers. The post explains how we responded and shares steps you can take to protect your services. Additionally, we have published a second deep dive blog post to help you navigate and implement your own fixes. What happened? A set of critical vulnerabilities affecting all maintained PHP versions (php2shell) was disclosed, involving how the PHP engine handles fatal errors like memory exhaustion, timeouts, and dropped connections. To help protect customer environments, Fastly’s Security Research team, in collaboration with OpenAI and community partners, has developed a Virtual Patch for CVE-2026-109618 and CVE-2026-109619. To learn more about this vulnerability and our proactive protections, please read the blog posts linked in the reference section below. What you can do We strongly advise taking the following recommended actions: Apply Virtual Patching: Fastly Next-Gen WAF customers are strongly encouraged to apply the Virtual Patch for CVE-2026-109618 and CVE-2026-109619 across all vulnerable Edge and on-prem services. Opting in ensures you automatically receive updates as the rule is refined. Audit Application Servers: Identify all application servers running mod_php or php-fpm and treat all PHP applications as potentially vulnerable. Patch PHP Upstream: Apply official upstream patches. Patches are available in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 . For PHP 7.4, 8.0, and 8.1, or older versions, verify available patches with your Linux/package distributor. Fastly is actively monitoring for exploitation and new variants. Please stay aware of any further updates as this situation develops. Customers with any questions, requiring emergency WAF onboarding, or needing support may engage with our Support team through [email protected] or by contacting your designated account management team members. Reference: Critical RCE Vulnerabilities Discovered in Core PHP: CVE-2026-109618 and CVE-2026-109619 Fastly’s Proactive Protection for PHP2Shell, Critical React RCE CVE-2026-109618 and CVE-2026-109619

    Latest: A security disclosure regarding php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) was published on October 21, 2026. In addition to implementing certain mitigations, …

  3. Ongoing ● 8d 10h
    Started Oct 20, 2026, 01:18 AM UTC
    PlatformEuropePlatformEuropePlatformPlatformPlatformPlatformPlatformPlatform
    Timeline · 1 update
    • investigating · Oct 20, 2026, 01:18 AM UTC

      Our previous status post about this migration said no action was required. That was incorrect for Compute services that use mxp-milan-it as a shield location. If you have a Compute service that shields at Milan (MXP), you need to update it by November 2, 2026. Fastly can’t make this change for you because the shield location is set in your service’s code or Compute Config Store. We’re sorry for the confusion. What’s changing? Fastly is decommissioning the Milan (MXP) POP. Beginning October 26, 2026, and concluding by November 2, 2026, Fastly will gradually redirect shield traffic for the mxp-milan-it shield location to our Milan (BGY) POP. During this migration period, Compute services that reference mxp-milan-it will be redirected to bgy-milan-it. After the migration period ends, mxp-milan-it will no longer be a valid shield location, and Compute services that still reference it will get an error when creating the shield. How your service behaves after that depends on how your code handles that error. What’s next? What do I have to do? Compute services If your Compute service uses mxp-milan-it as a shield location, update it to bgy-milan-it before November 2, 2026. We recommend making this change as soon as possible. Find every place your service sets mxp-milan-it as a shield location, including shield names in your code and any values your code loads from a config store. Replace mxp-milan-it with bgy-milan-it. If you changed your code, build and deploy a new version of your service. If the shield name comes from a config store, update the stored value. If you manage your service with Terraform or other automation, update the shield name there too, so a later deployment doesn’t restore mxp-milan-it. For details on Compute services, see our Shielding documentation. Varnish Configuration Language (VCL) services If your VCL service uses standard shielding configuration, no action is required. Fastly will redirect your shield traffic to Milan (BGY) automatically. If your custom VCL or VCL snippets reference mxp-milan-it or the MXP POP in your own logic, update those references to bgy-milan-it before November 2, 2026. You can also switch your shield location to “bgy-milan-it” yourself in the Fastly control panel. See our Shielding documentation. When you switch to bgy-milan-it, your origin servers may see a temporary increase in requests while the cache fills in Milan (BGY). If you have any questions, please contact our Support team through https://support.fastly.com or your account team.

    Latest: Our previous status post about this migration said no action was required. That was incorrect for Compute services that use mxp-milan-it as a shield location. If you have a Compute…

Recent outages & incidents

Past 90 days
  1. Resolved 2h 6m
    Started Oct 28, 2026, 05:02 AM UTC · Resolved Oct 28, 2026, 07:08 AM UTC
    North AmericaNew York (TSS)North AmericaNew York (TSS)PlatformPlatform
    Timeline · 2 updates
    • investigating · Oct 28, 2026, 05:02 AM UTC

      Traffic in New York (TSS) has been temporarily rerouted. All other locations and services are unaffected.

    • resolved · Oct 28, 2026, 07:08 AM UTC

      This event has been resolved.

    Latest: This event has been resolved.

  2. Resolved 1h 37m
    Started Oct 27, 2026, 11:05 PM UTC · Resolved Oct 28, 2026, 12:42 AM UTC
    FanoutFastly ComputeConfig StoreKV StoreSecret StoreAI AcceleratorEdge Cloud ServicesWebsocketsNext-Gen WAF (NGWAF)Compute
    Timeline · 4 updates
    • investigating · Oct 28, 2026, 12:10 AM UTC

      We are investigating elevated errors to our Compute, Next-Gen WAF (NGWAF) Services

    • investigating · Oct 28, 2026, 12:34 AM UTC

      Our engineers believe they have identified contributing factor causing the issue impacting the Compute, Next-Gen WAF (NGWAF) Services. We are now developing a fix, and will post a new update once it has been fully implemented and we see signs of recovery. All other products and services are unaffected by this incident.

    • monitoring · Oct 28, 2026, 12:35 AM UTC

      Engineering has confirmed the impact to Compute, Next-Gen WAF (NGWAF) Services has been mitigated.

    • resolved · Oct 28, 2026, 12:42 AM UTC

      Engineering has confirmed that Compute, Next-Gen WAF (NGWAF) Services has been fully restored. Customers may have experienced intermittent 5xx errors from 23:05 UTC on October 27 to 00:23 UTC on October 28. Service has been fully restored. This incident is resolved. Affected customers may have experienced impact to varying degrees and to a shorter duration than as set forth above. Note: Our Customer Escalation Management team will update the start date and time of the initial "investigating" status post upon the resolution of this incident. This update is meant to provide our customers and their end users with a potential impact window. The date and time mentioned in the message above indicates when the status post was requested by our Acute Incident Response team. Status Post, Created Date/Time: 2026-10-28 00:15:23 UTC

    Latest: Engineering has confirmed that Compute, Next-Gen WAF (NGWAF) Services has been fully restored. Customers may have experienced intermittent 5xx errors from 23:05 UTC on October 27 t…

  3. Resolved 4h 19m
    Started Oct 27, 2026, 01:55 PM UTC · Resolved Oct 27, 2026, 06:14 PM UTC
    AfricaCape Town (CPT)Johannesburg (JNB)PlatformPlatformPlatformPlatformPlatformAfricaCape Town (CPT)
    Timeline · 4 updates
    • investigating · Oct 27, 2026, 03:46 PM UTC

      We are investigating an issue causing errors and increased latency for our network services in the Johannesburg (JNB) Point of Presence (POP). Please note that customers in the Cape Town (CPT) POP were temporarily impacted by this issue between 14:35 and 14:54 UTC; however, services in CPT have since fully recovered. Our engineers are actively working to diagnose the contributing factor. We will provide another update as more information becomes available or within the next hour.

    • investigating · Oct 27, 2026, 04:09 PM UTC

      Our engineers have identified the contributing factor causing the issue impacting our network services in the Johannesburg (JNB) Point of Presence (POP). Our engineers are now developing a fix, and we will post a new update once it has been fully implemented and we see signs of recovery. Customers in the Cape Town (CPT) POP were temporarily impacted between 14:35 and 14:54 UTC. Services in CPT have since fully recovered. All other products and services remain unaffected by this incident.

    • monitoring · Oct 27, 2026, 05:28 PM UTC

      Our engineers have taken steps to recover the affected systems in the Johannesburg (JNB) Point of Presence (POP) and are gradually returning traffic to the site. We are observing a gradual restoration of services, though some customers may continue to experience intermittent issues as the system stabilizes. Customers in the Cape Town (CPT) POP were temporarily impacted between 14:35 and 14:54 UTC. Services in CPT have since fully recovered. Our team is actively monitoring the recovery and will post another update once services are fully restored.

    • resolved · Oct 27, 2026, 06:54 PM UTC

      Our engineers have confirmed that our network services in the Johannesburg (JNB) Point of Presence (POP) have been fully restored. Customers may have experienced errors and increased latency from 13:55 to 17:31 UTC on October 27, 2026. Customers in the Cape Town (CPT) POP were temporarily impacted between 14:35 and 14:54 UTC. Service has been fully restored. Affected customers may have experienced impact to varying degrees and for a shorter duration than stated above. Note: Our Customer Escalation Management team will update the start date and time of the initial "investigating" status post upon the resolution of this incident. This update is meant to provide our customers and their end users with a potential impact window. The date and time mentioned in the message above indicates when the status post was requested by our Acute Incident Response team. Status Post, Created Date/Time: 2026-10-27 15:48:36 UTC

    Latest: Our engineers have confirmed that our network services in the Johannesburg (JNB) Point of Presence (POP) have been fully restored. Customers may have experienced errors and increas…

  4. Resolved 2h 21m
    Started Oct 26, 2026, 04:36 PM UTC · Resolved Oct 26, 2026, 06:57 PM UTC
    StreamingOn-the-fly PackagerNetwork ServicesContent Delivery (CDN)StreamingOn-the-fly Packager
    Timeline · 4 updates
    • investigating · Oct 26, 2026, 06:24 PM UTC

      We are investigating an issue causing 503 errors for customers using On-the-Fly Packaging (OTFP). Our engineers are actively working to diagnose the contributing factor. We will provide another update as more information becomes available or within the next hour.

    • investigating · Oct 26, 2026, 06:51 PM UTC

      Our engineers believe they have identified the contributing factor causing the issue impacting On-the-Fly Packaging (OTFP). Our engineers are now developing a fix, and we will post a new update once it has been fully implemented and we see signs of recovery. All other products and services remain unaffected by this incident.

    • monitoring · Oct 26, 2026, 07:05 PM UTC

      The fix has been successfully deployed, and we have observed a recovery of On-the-Fly Packaging (OTFP). Error rates and latency have returned to nominal levels. Our team will continue to monitor the platform to ensure stability before we resolve this incident.

    • resolved · Oct 26, 2026, 07:14 PM UTC

      Our engineers have confirmed that On-the-Fly Packaging (OTFP) has been fully restored. Customers may have experienced 503 errors from 16:36 to 18:57 UTC on October 26, 2026. This incident is resolved. Affected customers may have experienced impact to varying degrees and for a shorter duration than stated above Note: Our Customer Escalation Management team will update the start date and time of the initial "investigating" status post upon the resolution of this incident. This update is meant to provide our customers and their end users with a potential impact window. The date and time mentioned in the message above indicates when the status post was requested by our Acute Incident Response team. Status Post, Created Date/Time: 2026-10-26 18:28:01 UTC

    Latest: Our engineers have confirmed that On-the-Fly Packaging (OTFP) has been fully restored. Customers may have experienced 503 errors from 16:36 to 18:57 UTC on October 26, 2026. This i…

  5. Resolved 4h 30m
    Started Oct 22, 2026, 07:00 AM UTC · Resolved Oct 22, 2026, 11:30 AM UTC
    Mumbai (BOM)PlatformIndiaPlatformPlatformPlatformPlatformPlatformPlatformIndia
    Timeline · 2 updates
    • investigating · Oct 22, 2026, 07:00 AM UTC

      Fastly Engineers detected a performance impacting event affecting the Mumbai (BOM) data center. All other data centers and services were unaffected. The issue has been resolved and we are monitoring performance closely.

    • resolved · Oct 22, 2026, 11:30 AM UTC

      This event has been resolved.

    Latest: This event has been resolved.

See the full Fastly outage history

48 more incidents in the last 90 days, plus the full multi-year archive of per-service events and update timelines.

Browse Fastly outage history →

Or sign up free to get alerts when Fastly breaks · 10 free monitors · No credit card

Incident record

Since April 2026 · Fastly Statuscast · 257 components checked every 5 minutes
177incidents recorded
177last 12 months
53last 90 days
2 daystypical duration, 12 months

The longest incident in the last year, Port Blair (IXZ) Rerouted Traffic on July 28, 2026, ran for 38 days. 59 maintenance windows announced in the same period.

Most affected components, last 12 months

  • Platform61
  • Platform52
  • Platform41
  • Platform40
  • Platform30

Latest incidents

Outage history

Past 90 days · 53 incidents View full outage history →