All Systems Operational
Data Collection ? Operational
Indexing ? Operational
User Interface Operational
Alerting Operational
Cognitive Insights ? Operational
API ? Operational
Live Tail ? Operational
Degraded Performance
Partial Outage
Major Outage
Past Incidents
May 29, 2020

No incidents reported today.

May 28, 2020
Completed - The scheduled maintenance has been completed.
May 28, 20:59 IDT
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
May 28, 16:25 IDT
Scheduled - What's happening?
To support encrypted shipping of your logs and metrics, shipping methods over SSL/TLS use a public certificate that's authenticated by a trust chain, issued by a certificate authority. Lower protocols like TCP need guidance on "who to trust". That guidance includes a certificate that you install in your environment. All this is so your data can be read by, only after you can be sure we are who we say we are.

At the end of May, this chain of trust expires, and we need to rotate certificates so you can keep sending your data without any issues.

To make sure there's a smooth transition, we'll rotate certificates and establish a new chain of trust a few days early. This new chain won't expire until 2038.

This means you'll need to update any of your data shipping configurations that make use of our certificate chain.
IMPORTANT: Configurations need to be updated before May 28 to avoid disruptions in sending your data to

What's affected?
Many of the shipping methods covered in the docs are affected, but not all. This does not affect data that you're sending unencrypted or with higher protocols.

This could affect you if any of these are true:
- You're sending data using any Beats shippers (such as Filebeat, Metricbeat, or Winlogbeat)
- You're sending data with Logstash over SSL
- You've deployed our Docker images or Kubernetes configmaps
What this does not affect:
This does not affect data sent over HTTP or HTTPS, including bulk shipping. This also does not affect any of the code libraries covered in the docs.

How do I update my certificates?
The actions you need to take depend on how you're shipping your data. The lists below show the docs that include information on updating your certificates. You can find these docs here:

You'll need to do this before May 28 to avoid disruptions. You can remove the old certificates only after June 5.

Affected log shipping methods:
- Filebeat
- Logstash
- Active Directory for Windows Server (Filebeat)
- Apache (Filebeat)
- auditd (Filebeat)
- Check Point (Filebeat)
- Cisco ASA Server (Filebeat)
- Docker
- Elastic container service
- Fail2ban (Filebeat)
- Falco (Filebeat)
- FortiGate (Filebeat)
- GitLab (Filebeat)
- HashiCorp Vault (Filebeat)
- Jenkins (Filebeat)
- JSON uploads
- Juniper SRX (Filebeat)
- Mcafee ePO (Filebeat)
- MySQL (Filebeat)
- Network devices (Filebeat)
- nginx (Filebeat)
- OSSEC (Filebeat)
- Palo Alto Networks (Filebeat)
- Puppet (Filebeat)
- Stackdriver
- Wazuh (Filebeat)
- Windows (Filebeat)
- Windows Defender (Filebeat)
- Zeek (Filebeat)

Affected metrics shipping methods:
- Azure Monitor metrics (Metricbeat)
- Docker
- EC2 Auto Scaling
- EC2
- Kubernetes metrics (Metricbeat)
- Lambda
- S3
- System metrics (Metricbeat)

I use a different solution for sending data. Does this affect me?
This may affect custom or third party solutions that aren't covered in the docs. If you send any data to over TCP, check your configurations. If they use our trust chain, update them before May 28 to use the old and the new certificates.

You can download the new public certificate from here:

How can I be sure my configuration change works?
Starting Monday, May 18th, we'll open up test data receivers so you can confirm the new configurations will work after we switch to the new chain of trust.

You can test your new configuration by temporarily pointing your shipper to a testing URL for your region (in the table below). You'll know the configuration is good (and that it will work after May 28) if you see the data coming into your account.

After you've confirmed the configuration is good, revert your shipper to the production URL for your region.

US East (Northern Virginia): Test using
Asia Pacific (Sydney): Test using
Canada (Central): Test using
Europe (Frankfurt): Test using
West Europe (Netherlands): Test using
Europe (London): Test using
West US 2 (Washington): Test using

We know we're an important part of your work and we want to make sure all your data stays available to you.

If you have any questions, your Customer Success Engineer and the Support team ( are here to help.
Please reach out any time.
May 14, 22:53 IDT
May 27, 2020
Resolved - Fix has been implemented, the web application is back up to all customers
May 27, 13:21 IDT
Identified - The web application is experiencing elevated error rates, through multiple regions.
Logs are being indexed as usual, and alerts keep firing.
We have found the root cause and working promptly on a fix.
May 27, 13:17 IDT
May 26, 2020

No incidents reported.

May 25, 2020

No incidents reported.

May 24, 2020

No incidents reported.

May 23, 2020

No incidents reported.

May 22, 2020

No incidents reported.

May 21, 2020

No incidents reported.

May 20, 2020
Resolved - This incident has been resolved.
May 20, 16:22 IDT
Update - We are continuing to investigate this issue.
May 20, 16:16 IDT
Investigating - We are currently investigating this issue.
May 20, 16:15 IDT
May 19, 2020

No incidents reported.

May 18, 2020

No incidents reported.

May 17, 2020

No incidents reported.

May 16, 2020

No incidents reported.

May 15, 2020

No incidents reported.