2022-08-04 09:40 UTC We are investigating bug, which causing error pages rendered as html source code.
2022-08-04 09:55 UTC Issue is now resolved all systems are working normally.
We are sorry for the inconvenience.
2022-08-04 09:40 UTC We are investigating bug, which causing error pages rendered as html source code.
2022-08-04 09:55 UTC Issue is now resolved all systems are working normally.
We are sorry for the inconvenience.
We are experiencing an issue with possibility of tables with _tmp suffix might be dropped.
If you manipulate with a table <X> and there also exist a table with name <X>_tmp, the table <X>_tmp could be accidentally dropped.
These tables (<X> and <X>_tmp) have to be in the same bucket and your project has to have Snowflake backend. We found the root cause and fix will be deployed in 2 hours.
Affected tables will be restored.
2022-08-02 17:00 UTC - We have deployed the fix of this issue and fixed affected tables. The issue is now resolved. We contact affected customers directly.
We are sorry for the inconvenience.
2022-08-02 7:00 UTC We are investigating delayed orchestrations on Azure North Europe Keboola Connection stack (https://connection.north-europe.azure.keboola.com). Next update in 30 minutes.
2022-08-02 7:30 UTC After our investigation, problem starts at 6:00 UTC. Orchestrations that should have be scheduled after this time, were delayed in the order of minutes or tens of minutes. Situation returned back to normal at 7:15 UTC and all orchestrations are scheduled properly.
2022-07-27 11:12 UTC - Snowflake transformations does not respect selected warehouse size during input mapping which might lead to slower processing times. We are working on a fix which might be deployed in 4 hours.
2022-07-27 14:59 UTC - The fix was not yet deployed due to unexpected complications. We are working on it and the fix should be deployed in 4 hours.
2022-07-27 17:34 UTC - The fix was deployed. All Snowflake transformations are now using correct Warehouse size for execution. The issue is now resolved.
We are experiencing an issue with possibility of tables with _tmp suffix might be dropped. These tables have to be in the same bucket, and there have to exist a table with the same name, just without the _tmp suffix. We found the root cause and we are working on a fix which might be deployed in 4 hours.
2022-07-27 11:17 UTC - We have deployed the fix of this issue. Affected customers were contacted directly. We'll undrop affected tables.
2022-07-27 16:34 UTC - We have fixed affected tables. The issue is now resolved. We are sorry for the inconvenience.
Starting on August 8th we will resume migrations to the new Job Queue in our Azure North Europe stack.
This is a follow up to the previous round of migration, and all relevant information can be found in our previous post.
If you're not sure if your project is already on the new Job Queue, go to orchestrations in your project and if the url ends with "orchestrations-v2" then your project is already on the new Job Queue.
If you have any questions regarding the migration, please contact us via support@keboola.com
Today at 07:38 (UTC) a new version (1.9.1) of PostgreSQL data destination was released which introduced a bug causing some configurations to write no data. The component version was rolled back to 1.9.0 at 13:48 (UTC) and everything should work as expected.
If you still encounter similar symptoms please let us know.
We're sorry for this inconvenience.
We apologize for any inconvenience.
We are aware of a bug in the UI that prevents tables in the input mapping list from being visible. We are in the process of reverting the release causing it and will find a fix afterward.
UPDATE 18:15 CET: The release introducing the bug was reverted so it does not happen again. You may need to reload the browser. The bug was introduced today at 16:04 CET.
2022-07-02 7:45 UTC We are investigating delayed orchestrations on Azure North Europe Keboola Connection stack (https://connection.north-europe.azure.keboola.com). Next update in 30 minutes.
2022-07-02 8:40 UTC After our investigation, problem starts at 6:40 UTC. Orchestrations that should have be scheduled after this time, were delayed in the order of minutes or tens of minutes. Situation returned back to normal at 7:45 UTC and all orchestrations are scheduled properly.
We are sorry for the inconvenience.