Is Fastly down?
Last checked 4m agoNo new incidents. 1 long-running issue listed below.
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.
Active incidents 3
- 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…
-
- 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, …
-
- 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- 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.
-
- 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…
-
- 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…
-
- 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…
-
- 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 minutesThe 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
- New York (TSS) Rerouted Traffic
Traffic in New York (TSS) has been temporarily rerouted. All other locations and services are unaffected.
- Elevated Errors for Compute, Next-Gen WAF (NGWAF)
We are investigating elevated errors to our Compute, Next-Gen WAF (NGWAF) Services
- Cape Town (CPT), Johannesburg (JNB) with Possible Impact
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…
- New York (TSS) Rerouted Traffic ResolvedStarted Oct 28, 2026, 05:02 AM UTC · Resolved Oct 28, 2026, 07:08 AM UTC · 2h 6m
- Started Oct 27, 2026, 11:05 PM UTC · Resolved Oct 28, 2026, 12:42 AM UTC · 1h 37m
- Started Oct 27, 2026, 01:55 PM UTC · Resolved Oct 27, 2026, 06:14 PM UTC · 4h 19m
- Started Oct 26, 2026, 04:36 PM UTC · Resolved Oct 26, 2026, 06:57 PM UTC · 2h 21m
- Started Oct 23, 2026, 02:20 AM UTC · ● 5d 9h
- Started Oct 22, 2026, 07:00 AM UTC · Resolved Oct 22, 2026, 11:30 AM UTC · 4h 30m
- Started Oct 21, 2026, 07:26 PM UTC · ● 6d 16h
- Started Oct 21, 2026, 10:20 AM UTC · Resolved Oct 21, 2026, 12:20 PM UTC · 2h