cloud.gov Status Page

Aug 5, 2026 · resolved Aug 5

# SES service broker outage on August 5, 2026 ## Summary From approximately 9:13 AM ET to 9:45 AM ET on Wednesday August 5, 2026,[ ](http://cloud.gov)the [SES service broker](https://docs.cloud.gov/platform/services/aws-ses/) was unavailable. During this time, customers could not create, update, or delete brokered SES services. The outage affected only the management of brokered SES services. Existing service instances and email delivery were not interrupted. ## Impact During the incident, customers were unable to: * Create new brokered SES services * Update existing brokered SES services * Delete existing brokered SES services No action was required from customers after service was restored. ## Cause An automated cleanup process deleted a container image that was still being used by the deployed SES service broker. When the broker restarted during a production deployment, it could not retrieve the image and failed to start. ## Timeline All times are Eastern Time. * August 4, 4:24 AM - An automated pipeline created a new container image for the SES service broker * August 4, 3:03 PM - An automated process deleted the container image used by the deployed broker * August 5, 7:17 AM - A [Cloud.gov](http://cloud.gov) production deployment began. * August 5, approximately 9:13 AM - The broker attempted to restart but could not retrieve its container image. * August 5, approximately 9:28 AM - The [Cloud.gov](http://cloud.gov) team received an alert and began investigating. * August 5, approximately 9:45 AM - Engineers manually redeployed the broker with an available container image and restored service. ‌ **Resolution** [Cloud.gov](http://cloud.gov) manually redeployed the SES service broker using an available container image. The team then reran the automated deployment pipeline and confirmed that the deployment and acceptance tests completed successfully. **Follow-up Actions** [Cloud.gov](http://cloud.gov) is taking the following actions to reduce the risk of a similar incident and improve recovery: * Improve monitoring and alerting for SES service broker outages. * Update the container image cleanup process so it does not delete images that are still in use. * Update the deployment process so the SES service broker references the intended current container image. Thank you for your patience while we resolved this issue. Questions may be sent to us at [support@cloud.gov](mailto:support@cloud.gov).

Jun 11, 2026 · resolved Jun 12

**Summary** From approximately 12:22 PM to 7:19 PM ET on Thursday, June 11, 2026, [Cloud.gov](http://cloud.gov) service broker management actions were unavailable. During this window, customers could not create, update, or delete brokered services. Existing brokered services, including S3 buckets, RDS databases, and other already provisioned services, remained available. Customer applications continued to run, and we did not observe application downtime from this incident. **Impact** During the incident, customers were unable to: * Provision new brokered services * Update existing brokered services * Delete existing brokered services Existing service instances and customer applications were not interrupted. **Timeline** All times are Eastern Time. * 12:22 PM - An automated credential rotation process changed IAM credentials used by [Cloud.gov](http://cloud.gov) service brokers. * 12:57 PM - A [Cloud.gov](http://cloud.gov) engineer identified that some service broker IAM credentials were no longer working as expected. * 1:35 PM - The [Cloud.gov](http://cloud.gov) team began coordinated incident response. * 2:34 PM - The [Cloud.gov](http://cloud.gov) team began restoring IAM credentials and redeploying affected service brokers. * 7:19 PM - The final service broker was redeployed. All [Cloud.gov](http://cloud.gov) service brokers were confirmed operational. **Resolution** [Cloud.gov](http://cloud.gov) created replacement IAM credentials, redeployed the affected service brokers, and tested broker operations. After validation, the team confirmed that customers could again create, update, and delete brokered services. **Follow-up Actions** [Cloud.gov](http://cloud.gov) will take the following actions to reduce the change of a similar incident and improve recovery: * Add alerting to detect service broker IAM credential failures sooner. * Review IAM credential rotation procedures for service brokers. * Add stronger safeguards for automated credential rotation. * Improve automation for redeploying service brokers after credential changes. * Review incident response runbooks for service broker credential failures. Thank you for your patience while we resolved this issue. If you have any questions, please contact us at [support@cloud.gov](mailto:support@cloud.gov).

May 28, 2026 · resolved May 28

This incident has been resolved.

Apr 8, 2026 · resolved Apr 9

This incident has been resolved.

Mar 17, 2026 · resolved Mar 17

Summary From March 17, 2026 around 9:30 AM ET to March 19, 2026 around 3:10 PM ET, some application JSON logs were not ingested successfully to Cloud.gov Logs. Timeline - March 6, 2026, 10:25 AM ET - Changes were merged to the logging system configuration to make some subfields of application JSON logs searchable and aggregatable - March 17, 2026, 9:30 AM ET - Changes to JSON log field parsing begin deploying to Cloud.gov Logs system. Some JSON application logs began to fail ingestion at this point - March 19, 2026, 2:39 PM ET - Automated testing alerts Cloud.gov engineers to ingestion failures in Cloud.gov Logs. Engineers begin to investigate. - March 19, 2026, 2:59 PM ET - A Cloud.gov engineer determines that updated JSON application log parsing of timestamp fields is causing some logs to fail ingestion and slowing the overall log ingestion rate - March 19, 2026, 3:06 PM ET - A fix is deployed to change the field type to “string” for JSON log timestamp fields March 19, 2026, 3:10 PM ET - JSON log ingestion errors are resolved and logs are ingesting successfully Impact Only JSON application logs that included a “ts” field or a “timestamp” field which could not be properly parsed as a date (e.g. “1.8543923523”) failed to ingest to Cloud.gov Logs during the incident. While these logs were not ingested to Cloud.gov Logs successfully, they were ingested to offline storage that is not accessible to customers, but can be accessed by the Cloud.gov engineers if necessary. Resolution The type of the timestamp field for JSON application logs was changed to “string”, which allows even values that aren’t valid timestamps or dates to be ingested. Next Steps The Cloud.gov team will hold a retrospective to further analyze the causes of this incident and how to improve our operations. We will post our findings as a post-mortem to this incident. Thank you for your patience. If you have any questions, please contact us at support@cloud.gov.

Is cloud.gov down right now?

No — cloud.gov is up. All systems operational as of Aug 19, 9:43 PM UTC.

What is cloud.gov's current status?

cloud.gov: All Systems Operational. Alert24 checks cloud.gov's status page continuously and can notify you the moment it changes.

How do I get alerted when cloud.gov goes down?

Alert24 monitors cloud.gov and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.