# Platform Release 383 - August 2026 **URL:** \ **Category:** Announcements\ **Created:** [August 27, 2026, 4:25pm UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536 "2026-08-27T16:25:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![L\_Churchill](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/l_churchill/32/5200_2.png) [@L\_Churchill](https://community.tulip.co/u/L_Churchill)\ **Post date:** [August 27, 2026, 4:25pm UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/1 "2026-08-27T16:25:16Z")
🎉 Exciting news - Release 383 is here! The Tulip team has rolled out fresh updates across the platform, along with some bug fixes. Check out the [release notes](https://support.tulip.co/docs/platform-release-383-august-2026) and dive into what’s new. Share your thoughts and questions below ⬇ ---
**Author:** ![ta-aoki](https://avatars.discourse-cdn.com/v4/letter/t/a587f6/32.png) [@ta-aoki](https://community.tulip.co/u/ta-aoki)\ **Post date:** [October 7, 2026, 3:16am UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/2 "2026-10-07T03:16:30Z")
How is this fixed? Does it now just stop retrying, or does it now discard with some kind of notification to the users? > _PLAT-56349 Fixed an issue where an app completion that failed to save for a permanent reason (for example, a value too large for its column) was retried until the retry limit was reached and then discarded silently._ It would be also great if those issues can also be viewed from the suggested event logs. > [@Event log to record Tulip error messages](https://community.tulip.co/t/event-log-to-record-tulip-error-messages/5902): > > It would be nice to have an event log like in windows. (doesn’t have to be all flashy, just a read-only tulip table will be more than enough.) Every time there is a Tulip error message an entry is made in the event log with station name, App name, step name, user, date and time, error message, etc. This should also capture events when we use the “show error” trigger function. This will be very similar to the completions table, but for errors. The alternate method I can think of is for us to … ---
**Author:** ![Beth](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/beth/32/5987_2.png) [@Beth](https://community.tulip.co/u/Beth)\ **Post date:** [October 9, 2026, 5:50pm UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/3 "2026-10-09T17:50:04Z")
Hi @ta-aoki - thanks for the clarifying question here! With this change, the Player no longer keeps retrying (and ultimately resulting in silent failure). The failure is now routed to a separate save path that can send a data-integrity notification email, so it isn’t dropped silently. Temporary issues like network interruptions still retry as before. This was actually an internally found bug that we proactively fixed, and we did not see customers impacted by this. Regarding Event Log - the good news is the team is starting to scope out this feature, and I agree this could be a great place for this type of thing to reside. Would you be interested in chatting with me more regarding Event Log? If so, I will send you an email to coordinate a time to talk 🙂 ---
**Author:** ![ta-aoki](https://avatars.discourse-cdn.com/v4/letter/t/a587f6/32.png) [@ta-aoki](https://community.tulip.co/u/ta-aoki)\ **Post date:** [October 12, 2026, 6:24am UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/4 "2026-10-12T06:24:10Z")
> [@Beth](#): > > Would you be interested in chatting with me more regarding Event Log? Thank you. I am welcome to have a chat, but I wrote everything in this thread, so you can just read it too! > [@Event log to record Tulip error messages](https://community.tulip.co/t/event-log-to-record-tulip-error-messages/5902): > > It would be nice to have an event log like in windows. (doesn’t have to be all flashy, just a read-only tulip table will be more than enough.) Every time there is a Tulip error message an entry is made in the event log with station name, App name, step name, user, date and time, error message, etc. This should also capture events when we use the “show error” trigger function. This will be very similar to the completions table, but for errors. The alternate method I can think of is for us to … ---
**Author:** ![Beth](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/beth/32/5987_2.png) [@Beth](https://community.tulip.co/u/Beth)\ **Post date:** [October 13, 2026, 2:59pm UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/5 "2026-10-13T14:59:20Z")
Thanks @ta-aoki ! I did read through your posts in the Event Log thread. Here’s what I took away: - **Builder access to errors:** you want App Info values for last system error message, timestamp, and trigger name, so app builder can build their apps to react better to errors. - **Troubleshooting and review:** you want the log to support both live troubleshooting and later review of runs, with CSV export into external log management. - **Offline and Player events:** you want “connection issue” and “trigger running too long” events captured in the Player, then uploaded once connected, so Account Owners can review them and understand potential impacts from connectivity disruptions - **Silent failures:** you’d like issues like above (failed completion saves) to appear in the event log too. We will take all of this into the scoping work. I’ll send a few short additional questions by email so I don’t make you repeat anything. If anything above is off, please correct me. ---
**Author:** ![Nicolas](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/nicolas/32/3349_2.png) [@Nicolas](https://community.tulip.co/u/Nicolas)\ **Post date:** [October 14, 2026, 7:18am UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/6 "2026-10-14T07:18:18Z")
> [@Beth](#): > > the good news is the team is starting to scope out this feature, and I agree this could be a great place for this type of thing to reside. Would you be interested in chatting with me more regarding Event Log? If so, I will send you an email to coordinate a time to talk 🙂 Hi @Beth, we are very interested in these topics. Include us in the loop. The key pain point to solve for us is that today there are +2500 users, spread around +15 sites. In case an operator faces an issue, the only information we have for investigation relies on operator feedback via chat or email with poor description (worst case “Tulip don’t work”). There is no log to understand what the operator has done, input, what triggered a failure, or connector call errors. Collecting error data, by apps, will help also Apps Buider to improve their apps or improve integration layer. ---
**Author:** ![nic.herbert](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/nic.herbert/32/9544_2.png) [@nic.herbert](https://community.tulip.co/u/nic.herbert)\ **Post date:** [October 14, 2026, 2:15pm UTC](https://community.tulip.co/t/platform-release-383-august-2026/16536/7 "2026-10-14T14:15:42Z")
Hi @Beth, We are also very interested in this topic as well. I think logging in general could use a revamp for users from what I can tell. I’m not sure how your own people support customer instances and do troubleshooting, but surely you have some sort of logging capability built in. If not, maybe this would be a good opportunity to improve for both sides. Here is my take: - You are utilizing Activity Logs, which from what messages I see, seem to align more with and Audit Log. These would be things like system changes (adding Connectors, changing an App), but could also include things like failed login attempts and those kinds of things. You could add user interactions in Apps as well, but I think I would make this user configurable (parameter on a button to log to Audit Log, or something like that). This might not be useful for everything, but some things might be needed for regulated industries. - On the other side, you have an event log, which captures pretty much everything else. How I’ve seen this done is a breakdown by module/capability with the option to adjust the logging level (TRACE, DEBUG, INFO, WARN, ERROR, etc…). So, for instance, you might have Connectors, Functions, Machines, etc… as high level modules to adjust logging on, and by default, I would assume most to be INFO. You could also get more granular by setting lower level items (like a specific Connector) to a higher level so you can debug a specific issue. - Then, on the other side, you might have user defined logging, which would be functions that app developers could use to log things on their own as they see fit. This would also go to the same event log as the above. - The final stage, I think, is providing a way to get the data out. As others have said, a simple export/download could be fine for the beginning, but one thing we really need is a tie into our Syslog/SIEM environment, particularly for the Audit Log. If you start with a good logging backend, then I think you can build onto it slowly over time. In all honesty, I see this as beneficial for not only us, but the Tulip team as well. Perhaps there are things that you would log for yourselves, but much of this would be really helpful and any central logging tool would be much appreciated. If you want examples of what I have seen as good implementations, I can certainly share.