Keboola - Status Page

File uploads temporarily disabled
MonitoringDegraded performance
  • Monitoring
    UTC
    Monitoring

    The security fix has been rolled out to all our services on all stacks, and file uploads are fully working again.

    This restores:

    * Synchronous table create/import requests to the Storage API that use multipart file upload, which no longer return HTTP 403


    Uploading files in the Keboola UI, attaching files in Kai chat, and the /upload-file and /write-table endpoints of the Storage API Importer were already restored in the previous update.

    No action is needed on your side. Asynchronous imports using files/prepare continued to work throughout.

    We apologize for the disruption. If you still see HTTP 403 errors on uploads, please contact our support.

  • Identified
    UTC
    Identified

    The security fix for the underlying issue has been released, and we are rolling it out across our services.

    File uploads through the Storage API Importer (import.*) are working again on all multi-tenant stacks, with the fix in place. This restores:

    • Uploading files in the Keboola UI

    • Attaching files in Kai chat

    • The /upload-file and /write-table endpoints of the Storage API Importer



    Still temporarily disabled:

    • Synchronous table create/import requests to the Storage API that use multipart file upload. These still return HTTP 403 until the fix reaches the Storage API.



    Asynchronous imports that use files/prepare work as before and can be used as a workaround.

    We will provide an update when new information is available.

  • Investigating
    UTC
    Investigating

    As a precautionary security measure, we have temporarily disabled multipart file uploads on all of our multi-tenant stacks

    Users may experience:

    • Failures when uploading files in the Keboola UI

    • Failures when attaching files in Kai chat

    • HTTP 403 errors from the /upload-file and /write-table endpoints of the Storage API Importer (import.*)

    • HTTP 403 errors on synchronous table create/import requests to the Storage API that use multipart file upload

    Asynchronous imports that use files/prepare still work and can be used as a workaround.

    We apologize for the disruption and will provide an update within 2 hours or when new information is available.

Snowflake transformations running slower than expected
Monitoring
  • Monitoring
    UTC
    Monitoring

    A fix has been deployed and Snowflake transformations are running on their configured backend size again.

    Cause: Because of an issue in our job execution environment, Snowflake transformations set to a medium or large backend size were run on the default (small) warehouse. This happened whether the size was set in the configuration, in a configuration row, or on the job itself (through the API or a flow). As a result, those jobs could take noticeably longer than usual.

    Resolution: The fix is now live on all stacks. On AWS EU (connection.eu-central-1.keboola.com), it has been in place since 12:58 CEST today (October 22). Jobs started after that time use the configured backend size again. We confirmed this for medium and large sizes, both on the job and in the configuration.

    Affected period: Medium and large Snowflake transformations ran on the default size during these periods:

    • AWS EU (eu-central-1): October 20 to October 22, 12:58 CEST

    • AWS US (us-east-1), Azure EU (north-europe), GCP US (us-east4): October 14 until the fix was deployed

    No action is needed. Your existing configurations will work as before. We are watching job run times to confirm everything is back to normal, and we will post a final update once we have.

  • Investigating
    UTC
    Investigating

    We are currently investigating reports of degraded performance affecting Snowflake transformations on our AWS EU (connection.eu-central-1.keboola.com) infrastructure. Users may notice Snowflake transformations taking noticeably longer than usual. Jobs set to a medium or large backend size may be running on the default size instead.

    Our engineering team has been alerted and is actively investigating the root cause.

    We apologize for the disruption and will provide an update within 1 hour or when new information is available.

AWS EU (eu-central-1) - Operational

99.8% uptime

GCP EU (europe-west3) - Operational

99.8% uptime

AWS US (us-east-1) - Operational

100% uptime

GCP US (us-east4) - Operational

100% uptime

Azure NE (north-europe) - Operational

100% uptime

Recent notices

Show history