Executions are now split into two dedicated views to make troubleshooting faster:

• List view: Filter executions by trigger payload data with AND/OR conditions, select custom date ranges within the 14-day retention window, and replay failed executions in bulk.
• Detail view: See a plain-language error message, a step-by-step timeline, and step logs, outputs, and the trigger payload in one place.

Log search now covers the full 14-day retention window (previously 48 hours), and the default search window is now 24 hours.

Additionally, the step logs and step result experience you love from the low-code designer is now available in code-native. Code-native integrations can use logger.section() to split onExecution logic into named sections, each with its own status, timing, and logs in the detail view. Execution sections require the latest version of @prismatic-io/spectral. Read more in the Code-Native Logging and Sections documentation.

We've rebuilt the charts across Prismatic. New interactive charts now appear on the Home page, integration landing pages, and your Customer, Instance, and Org Utilization views, so you can spot trends and jump straight to the executions behind any spike.

Toggle any chart between bar and line, and click into a day on the Executions Success/Failure chart to drill through to the underlying execution. Where available, you'll see up to 14 days of history.

We've redesigned the integration landing page to provide a one-stop shop for all information related to a specific integration. When you as an organization team member opens an integration, you'll see information about deployed instances, recent executions, marketplace configuration, and more.

Organizations can now see valuable insights into customer-built workflows through the Prismatic admin

Highlights:

• See the number of customer-built workflows separately from organization-built integrations
• View and filter Instances pages, logs, and execution history by their instance type (integration or workflow)
• Gain insights on workflow creation and enablement separately from integration instances on customer utilization pages

You can now enable debug mode in the integration designer or for a specific instance, which gives you more insight into time and memory metrics of your running flow.

When debug is enabled, a log line is emitted after each step that details how long the step took and how much memory was consumed.

Additionally, a debug object has been added to the context parameter so that you can optionally emit debug lines, measure how long certain tasks take within a code block or custom action, or measure how much memory is consumed by portions of your custom code when debug mode is enabled.

Learn more about debug mode.

Prismatic's public components will start transitioning to using debug mode rather than action-specific debug toggles.

For compliance reasons your organization may need to disable the storage of logs and step results. You can now disable the storage of logs and step results on a per-instance basis. For more information, see docs.

Replays of executions are now linked to the original execution. This makes it easier to query for failed executions, and replay only those executions that don't have a subsequent replay that succeeded.

See docs for more information, and the Examples repo in GitHub for the script mentioned in the above video.

Customers on enterprise plans can now stream logs and metrics to external logging services (like DataDog or New Relic). This is useful, since you likely already use a logging service to collect logs from your various applications. Now, your integration logs can live alongside the rest of your applications' logs.

Read more on our logging article.

Organizations with a professional or enterprise plan can now configure instances to automatically retry if an execution fails. You can control how many times an instance attempts to run with the same input, and how long it should wait between failed attempts. If you have an integration that relies on a flaky third-party API, for example, this minimizes interruptions for both your customers and your team.

You can also replay - manually retry - a specific failed execution of an instance.