Keboola Status

After June 1st 2015 we'll be enforcing strict limits on MySQL queries. All queries longer than 30 minutes (1800 seconds) will be terminated and the transformation will fail. You can now see duration of all queries longer than 2 minutes (120 seconds) in event log of any Transformation job so you can take optimization steps in advance.

We're introducing this limit to prevent errors like forgotten indexes and also to balance load on the shared MySQL Transformation database.

If your queries take significantly longer time than 30 minutes, please consider migrating your project to Redshift.

We're experiencing connectivity issues from AWS to some parts of the outer world (aka the Internet). As our transformation sandbox server (ovh-tapi.keboola.com) is not in AWS you may experience failures when creating sandboxes and credentials. If this is not resolved within AWS shortly, we'll be switching the sandbox server into AWS network. 

We will keep this post updated with the current status.

UPDATE (2:00pm PST): Connectivity seems to work fine now.

We're changing the way Facebook Extractor reacts to invalid accounts and tokens. Previously all invalid accounts/tokens were automatically disabled (with an error event in Storage) and the extractor continued with extraction. 

As this event was easy to miss and there was no other notification about an invalid token/account, we switched to a more strict behavior. Any invalid account/token will stop the execution of the whole job/orchestration with an explaining message:

You need then to change the token or disable the account manually. 

For any questions and comments do not hesitate to contact us at support@keboola.com.

We changed the naming conventions for MySQL provisioning. Instead of tapi_3800_sand and tapi_3800_tran, where 3800 is my token ID, the new database names are sand_232_3800 and tran_3800, where 232 is project ID for easier distinction between projects in your sandbox userspace. Existing credentials keep their database names.

We also added a little more information to events:

For all columns without a defined datatype in a Redshift transformation we added a default LZO compression. This will lead to a marginally slower transformation times but significantly less memory and disk space usage. 

You can override this behavior by defining a datatype without a compression.

Wait... what is R?

We've developed the backend and UI for transformations in R. All R transformations run in our public Docker image and have 1 GB memory allowance (will increase in near future). 

There's a guide how to develop and test your R scripts locally and a list of best practices and limitations.

Start typing you R scripts now!

AWS recently issued some information about connectivity issue in US-EAST-1 Region, where majority of our infrastructure is located. This may result in 500, 503 and 504 application errors within the infrastructure (our components) or when reaching out to other APIs (extractors). 

We're sorry for any inconvenience. we'll keep this post updated with current status. You can also check the current status at http://status.aws.amazon.com/, row Amazon Elastic Compute Cloud (N. Virginia).

---

9:23 AM PST We are investigating possible Internet connectivity issues in the US-EAST-1 Region.

10:09 AM PST We are continuing to investigate Internet connectivity issues in the US-EAST-1 Region.

From now on you can use all OUT tables in all transformations. Previous restrictions on using OUT tables in Redshift transformations were removed.

We had some issues in one of our components (job handling queue) between 10pm and 10:15pm PST on Sunday night (03:00–03:15 UTC Monday). That had resulted in some failed orchestrations (scheduled at that time or starting it's tasks at that time) . We're planning to upgrade the component in the coming weeks, but if the error occurs again, we'll upgrade it immediately. The upgrade will be accompanied with a short maintenance downtime.

We're sorry for any inconvenience.

After the maintenance window we've started experiencing some technical difficulties with our Elasticsearch cluster resulting in orchestration processing glitches. We're working on it and monitoring all processes closely. Please let us know at support@keboola.com if you encounter any unexpected behavior.