All Systems Operational
pro-us-east-1 Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
pro-eu-west-1 Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
pro-ap-southeast-2 Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
had a major outage
had a partial outage
Past Incidents
May 24, 2019

No incidents reported today.

May 23, 2019

No incidents reported.

May 22, 2019

No incidents reported.

May 21, 2019
Completed - The relevant SSL cert was renewed.
May 21, 00:21 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 20, 23:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on May 20, 2019 at 23:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 20, 21:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on May 20, 2019 at 23:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 20, 19:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on May 20, 2019 at 23:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 20, 17:00 UTC
Scheduled - External SSL certificates are about to expire during May 2019.

The change will renew external SSL certs.

none
Apr 23, 14:55 UTC
May 19, 2019

No incidents reported.

May 18, 2019

No incidents reported.

May 17, 2019

No incidents reported.

May 16, 2019
Completed - The security remediation for pro-us-east-1 has been successfully completed.
May 16, 01:10 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 15, 21:59 UTC
Scheduled - SRE is performing security remediation on pro-us-east-1.

Cluster compute nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/
May 15, 15:55 UTC
May 15, 2019
Completed - The security remediation for pro-eu-west-1 has been successfully completed.
May 15, 20:25 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 15, 18:01 UTC
Scheduled - SRE is performing security remediation on pro-eu-west-1.

Cluster compute nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/
May 15, 15:53 UTC
Completed - The security remediation for pro-ap-southeast-2 has been successfully completed.
May 15, 19:02 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
May 15, 17:01 UTC
Scheduled - SRE is performing security remediation on pro-ap-southeast-2.

Cluster compute nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/
May 15, 15:54 UTC
May 14, 2019

No incidents reported.

May 13, 2019

No incidents reported.

May 12, 2019

No incidents reported.

May 11, 2019

No incidents reported.

May 10, 2019

No incidents reported.