Current Status
All Systems Operational
Components
Recent Incidents
Intermittent issue accessing logs.fr.cloud.gov
noneMay 28, 2026 · resolved May 28
This incident has been resolved.
Cloud.gov Email Ticket Service Outage
noneApr 8, 2026 · resolved Apr 9
This incident has been resolved.
JSON application log ingestion failures
noneMar 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 [email protected].
New user signups not working
minorDec 29, 2025 · resolved Dec 31
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 [[email protected]](mailto:[email protected]). Next update: No further updates are planned.
Resolved - Cloudwatch Logs Ingestion Interruption
noneDec 4, 2025 · resolved Dec 17
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.
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 updates at 2 AM.

