.DkNUKaKx_ZLAT4m.webp?dpl=dpl_mxdY43eVEb2xCRXDR6YEJEsw9FBU){kind=small}
An integration platform should keep three records: what happened in each run, who changed what on the platform, and how the whole estate is behaving over time. Execution logs answer “why did this record fail?” Audit logs answer “who changed this workflow, and who looked at that data?” Monitoring answers “what’s failing more than usual?” All three need to reach the tools your team already watches, with masking and retention rules, because integration logs hold business data. Tray.ai keeps step-level execution logs, records platform actions as audit events, shows trends in its Insights Hub, streams logs to observability and SIEM tools, and can mask sensitive values. How long logs are kept, and whether they stream, depends on your plan.
The questions usually arrive at the worst moment. A workflow has stopped and someone needs to know why before the customer notices. Or an auditor wants to know who changed a sync that touches financial data, and when. Whether you can answer quickly depends on decisions made long before, about what the platform records and where that record goes.
Three records, three questions
| Record | The question it answers | Who uses it | What it should contain |
|---|---|---|---|
| Execution logs | Why did this run, or this record, fail? | The workflow's owner, support | Every run, every step, its status, and its input and output |
| Audit logs | Who changed what, and who looked at which data? | Security, compliance, platform admins | User and system actions on workflows, users, and credentials, plus access to sensitive data |
| Monitoring and insights | What's failing more than usual, and what's growing? | The platform owner | Runs, failures, and volume over time, across the whole estate |
Most teams have the first, some of the second, and very little of the third, which is why problems tend to be found by the people they affect.
Where monitoring breaks down
Logs nobody watches. Execution logs exist for every run, but nobody opens them until something has already gone wrong.
An alert for every failure. The first alerting setup usually sends a message for every failed run. Within weeks the channel is noise and people stop reading it, so the failure that matters gets missed with the rest.
Retention shorter than the audit window. If the platform keeps logs for a week and your auditors ask about last quarter, the answer has to come from somewhere else, or it doesn’t come at all.
Personal data sitting in logs. Integration logs show the input and output of each step, so they contain customer records, invoices, and anything else the workflow moves. Logs that help debugging can also widen who sees sensitive data.
Agents recorded somewhere else. When AI agents call tools over MCP, those calls need the same record as workflows. If they’re logged in a separate system, or not at all, the picture has a hole in it.
What to set up on day one
- An alerting workflow, routed to the people who own each workflow and filtered so that a repeated failure becomes one alert.
- Error-handling paths in each workflow, so expected failures are caught, retried, or set aside rather than stopping the run.
- Streaming to the tools you already use. Send logs to your observability or SIEM platform so failures can be seen across workflows and kept as long as your policies require. SIEM logging covers why security log feeds fail quietly.
- Retention that matches your compliance window, set deliberately rather than left at the default.
- Masking for sensitive fields, so people can debug without seeing personal data. See masking sensitive data in logs.
- An owner for every workflow, named somewhere the alert can find them.
Logging is also one of the first things a security review asks about, alongside credentials and access. Here’s what that review should ask an integration platform.
Agents and MCP need the same record
Every tool call an agent makes should be recorded like a workflow step: who was behind the request, which tool ran, which credentials it used, and what happened. Without that, an agent’s action can be seen in the target system but not explained. Governing the MCP servers and AI agents you already run covers how to get there, and MCP observability covers what to measure.
Does Tray.ai have audit logs and observability for workflows?
Yes, and how much history you keep depends on your plan.
Execution logs. Every workflow run produces a log showing whether the run succeeded or failed, the status of each step, and the input and output of every step. You can investigate a failed run from the log and replay it within your retention period.1
Audit logs. Tray records every action across the platform, and you can stream those logs to your own systems for oversight and compliance reporting. Support access is audited too: Tray’s support team sees your data only when you grant time-limited access, and every request and action generates an audit event.2 When an admin reveals a masked value in the logs, that’s recorded in the audit log too.3
Monitoring. The Insights Hub shows the health and performance of your workflows, with successful, failed, and terminated runs over time across the organization.4 An Alerting trigger runs an error-handling workflow when another workflow fails. It can be set for every workflow in your organization, for a workspace, or for individual workflows.5
Streaming. Log streaming sends log data to an external endpoint as runs happen, so you can analyze it in tools such as Datadog, Sentry, Redshift, New Relic, or Kibana, across workflows and by individual connector.6
Masking and retention controls. Log masking lets an admin hide a step’s input and output values in the logs while the workflow keeps running normally. It’s set up with your account team.3 On Team and Enterprise, you can reduce log retention to a single day or stop log data being written at all.7
Agents and MCP. For tools published through Tray Agent Gateway, logs show which user ran each tool and which authentication it used.8
| Pro | Team | Enterprise | |
|---|---|---|---|
| Execution log retention | 7 days from the last run | 7 days, or 30 days as an add-on | 30 days |
| Insights Hub history | 7 days | 30 days, or 180 days as an add-on | 180 days |
| Log streaming | Not included | Add-on | Included |
| Reduce retention or stop storing logs | Not available | Available | Available |
Sources: Tray.ai documentation and pricing.1,4,6,7,9
The trade-off is plain. On Pro, logs last seven days and don’t stream, so a team with a longer audit window needs Team with the add-ons, or Enterprise, where logs stream to a system you control and keep for as long as you choose.
Sources
- Tray.ai documentation, Debug logs: https://tray.ai/documentation/platform/enterprise-core/logs-debugging/debug-logs
- Tray.ai, Trust: https://tray.ai/trust/
- Tray.ai documentation, Log masking: https://tray.ai/documentation/platform/enterprise-core/security-compliance/log-masking
- Tray.ai documentation, Insights Hub: https://tray.ai/documentation/platform/enterprise-core/insights
- Tray.ai documentation, Alerting trigger: https://tray.ai/documentation/connectors/trigger/alerting-trigger
- Tray.ai documentation, Log streaming: https://tray.ai/documentation/platform/enterprise-core/logs-debugging/log-streaming
- Tray.ai documentation, Disabling log storage: https://tray.ai/documentation/platform/enterprise-core/logs-debugging/disabling-log-storage
- Tray.ai documentation, Agent Gateway overview: https://tray.ai/documentation/platform/artificial-intelligence/agent-gateway/overview
- Tray.ai, pricing: https://tray.ai/pricing/
