Cloudgov Status

**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).

This incident has been resolved.

This incident has been resolved.

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.

From approximately December 11, 2025 7:00 AM ET to December 31, 2025 7:30 AM ET, new [Cloud.gov](http://Cloud.gov) users attempting to complete new user signup not using their own agency IdP could not have completed the process. ‌ New users on existing IDP providers \([census.gov](http://census.gov), [DOJ.gov](http://DOJ.gov), [dol.gov](http://dol.gov), [EPA.gov](http://EPA.gov), [FDIC.gov](http://FDIC.gov), [fec.gov](http://fec.gov), [frtib.gov](http://frtib.gov), [GSA.gov](http://GSA.gov), [mcc.gov](http://mcc.gov), [nih.gov](http://nih.gov), [OMB.gov](http://OMB.gov), [onrr.gov](http://onrr.gov), [usaid.gov](http://usaid.gov), and [SSA.gov](http://SSA.gov)\) were NOT affected. ‌ The issue was related to a newer version of UAA for cross-site request forgery \(CSRF\) token enforcement of authenticated users from unknowingly executing unwanted actions with their current session.  An updated version of the activation form was rolled out to production the morning of December 31st. ‌ There is no customer required action.  If customers experience problems signing up at [Cloud.gov](http://cloud.gov), please reach out to [Cloud.gov](http://cloud.gov) support at [support@cloud.gov](mailto:support@cloud.gov).  ‌ Next update: No further updates are planned.

From November 19, 2025, 11:33 AM ET to December 15, 20925, 6 PM ET, [Cloud.gov](http://cloud.gov) Logs experienced elevated ingestion failures for a small subset of application logs. Based on ingestion metrics collected during the incident window, approximately 0.0042% of total log events failed ingestion. The issue was caused by a change to JSON log parsing combined with gaps in monitoring and test coverage. The parsing change was rolled back on December 15, and ingestion rates returned to normal. Log ingestion failures stopped by 6 PM ET. There is no required customer action. We are adding monitoring and alerts for ingestion failures and improving test coverage for JSON log parsing scenarios. Next update: No further updates are planned.

Resolved: Cloudwatch logs (for example, RDS logs) did not ingest into Cloud.gov Logs between December 4, 2025 at 11:14 AM ET and December 17, 1:45 PM ET. The issue was caused by a production change that required AES-256 encryption on the S3 buckets used for log ingestion. This change prevented a Lambda in the ingestion pipeline from successfully writing logs to S3. The Lambda did not surface errors, which delayed detection. At 1:45 PM ET on December 17, the bucket policy was corrected and log ingestion was resumed. No further customer action is required. Impact: Customers may see gaps in Cloudwatch log data for the affected time window. Prevention: We are improving ingestion monitoring, expanding end-to-end smoke tests, and updating our error handling so failures surface immediately. Next update: No further updates are planned.

## Summary From November 13, 2025 around 1:40 PM ET to November 19, 2025 around 7:30 PM ET, brokered service logs and metrics were ingesting, but not visible to customers. ## Timeline * November 5 - A change to the parsing logic for brokered service logs and metrics is made * November 13, ~1:40 PM ET - Change to parsing logic is deployed into production, causing the logs to become invisible to customers * November 19, ~7:30 PM ET - A [Cloud.gov](http://Cloud.gov) engineer notices the ingestion failures and makes a temporary fix for the bug, making brokered service logs and metrics visible to customers again * November 20 - A permanent fix for the bug is prepared and merged ## Impact * Brokered service logs \(currently only available for RDS databases\) and brokered service metrics \(available for RDS, S3, and Elasticsearch/OpenSearch\) were not visible to customers during the incident ## Resolution The bug in the parsing logic was fixed, allowing brokered service logs and metrics to be ingested and restoring visibility to customers. ## Next Steps * Re-ingest the brokered service logs and metrics affected by the incident so they are visible to customers * Improve automated testing for the logs system to ensure that all log types ingest successfully and and are searchable, which will ensure that there is no regression in log visibility from future changes Thank you for your patience. If you have any questions, please contact us at [support@cloud.gov](mailto:support@cloud.gov).

This incident has been resolved.

## Summary On August 21, 2025 from 11:22 AM ET to 11:45 AM ET, some [Cloud.gov](http://cloud.gov) customers experienced elevated 403 response rates when accessing hosted services. The issue was quickly identified and resolved, and service has remained stable since. ## Timeline * 11:22 AM - a configuration change was applied to traffic filtering rules. * 11:42 AM - Some customers report elevated 403 response rates * 11:44 AM - The configuration update was rolled back and error rates returned to normal.  * 11:45 AM - Service confirmed stable following log analysis. ## Impact * Some customers experienced elevated 403 errors between 11:22 AM and 11:45 AM. * Not all customers were affected due to the nature of the filtering rules. * For many, the impact was limited or not observed at all. ## Resolution The traffic filtering rule updates were reverted, restoring normal service. Monitoring confirmed that the elevated error rates stopped after the rollback. ## Next Steps * Establish a more formal review process for changes to traffic filtering. * Define when and how customers should be notified of planned changes. * Evaluate technical approaches to reduce the potential impact of similar updates. Thank you for your patience. If you have any questions, please contact us at [support@cloud.gov](mailto:support@cloud.gov).

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed. The rotated SSO root certificate has been switched to be the primary certificate used by cloud.gov UAA SAML integration. The expiring certificate is secondary and will expire tomorrow April 23rd. Customers who dynamically pull SAML metadata using https://login.fr.cloud.gov/saml/metadata, should not be affected. If you need to trust our SAML provider for your IDP, there are two methods for retrieving the new certificate: Use the provided SAML endpoints, such as https://login.fr.cloud.gov/saml/metadata Retrieve the root certificate manually from https://cloud.gov/docs/orgs-spaces/sso/#root-certificate Follow your agency's instructions for consuming and trusting our root certificate for SAML.

The scheduled maintenance has been completed.

We have completed the upgrade on https://logs.fr.cloud.gov. If you have login errors, please refresh/reload your browser and try again. If issues persist, please contact support@cloud.gov. Thanks - Peter and the Cloud.gov team

The scheduled maintenance on the GSA IDP has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.