As far as I know, we currently have no way at all to know how close we are to these limits and we only know something went wrong because the given task (automation run, custom tool Tulip API call, e-mail, SMS…) fails, which makes us contact Tulip support for more information.
It would be great to be more autonomous and have some charts that would allow us to monitor resource consumption (automation execution time, API calls, e-mails, SMS…) and the limits enforced in Tulip for automations and the Tulip API (especially regarding API calls, ideally categorized by source (app, automation, custom tool, cloud connector host, OPCH…)).
This would be very useful for Tulip integration in the customer’s infrastructure. This would notably allow to:
More easily know what was involved when a limit was exceeded
Monitor how changes to the infrastructure impact how limits are exceeded or not
Still, it would be useful to have a consolidated list of these tables somewhere. This would avoid having to check tables manually to see if everything is going well.
It would also be useful to have a consolidated list of automations that hit limits.
We have the same issue. We are setting up our structure and starting to see some 80% usage warnings that we would like to resolve before we scale up. We are thining that this is happening at midnight during reboort of many of our devices but it would be helpful to see a graph of the read / writes on a given table over time to monitor our current status and look for any rogue devices.
Hi @dBeckvall and @fti, thanks for keeping this thread going. I agree with the problem: today you mostly find out about a limit when something fails or a warning banner appears, and there’s no single place to see usage over time or which tables and automations are getting close. We’re aware limits have been a real pain point, especially in automations, and we’re actively looking at both the limits themselves and how visible they are. To be upfront, charts for usage against limits specifically aren’t on our near-term roadmap, so I don’t want to suggest they’re coming soon. This thread is still useful input for that work, and votes + examples here do help with prioritization.
In the meantime, @dBeckvall, a few things that may help with the midnight warnings. The banner on each table shows the date the 80% threshold was last exceeded, which can help confirm whether it lines up with your reboots. The limits are per table and per operation, and every service account on the instance shares them. So if a lot of devices hit the same table right after they restart, staggering the restarts or fetching records in one batched query instead of one request per record may help.