How to log and report on automated process runs

What matters here

• Log every step of every run to one place, not to each tool's own history.
• Join each run to the request it served. A run with no request is a log; a run with its request is a record.
• Record the decision, the rule behind it and the approver, not only success or failure.
• Report time by stage. A slow process is almost always one slow stage.
• Keep the record as long as the business needs it, which is usually longer than the tool keeps its logs.
• Alert when a stage drifts, before someone notices the process is slow.

Who this is for

You run operations or data for processes that span several teams. Each tool shows its own piece, and nobody can answer how long a request really took or who decided what without a day of digging.

How it works in practice

What has to happen between a process running and someone being able to answer a question about it.

1. 1

   Each step writes one line

   Run, step, time, inputs that matter, outcome, and who or what decided.

2. 2

   The line carries the request ID

   So every run for one request can be found together, across workflows.

3. 3

   Lines land in one place

   The warehouse, kept for as long as the business needs, separate from each tool's own history.

4. 4

   Stages are measured

   Time in each stage, how many requests waited, how many failed, by request type.

5. 5

   Drift raises an alert

   When a stage gets slower or fails more than usual, the process owner hears first.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Write one line per step, the same way everywhere

   Logs in five shapes can't be read as one record.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow and tray-patterns. The systems in play are
   Snowflake, Slack and the systems the process runs across, or
   whatever we run in those seats.
   
   Build one shared logging step that every workflow in the process
   calls after each meaningful step. It writes: request ID, run ID,
   workflow, step, stage, start and end time, outcome, the rule or
   person that decided, and the IDs of any records it created.
   
   Leave out personal data the report does not need. A run record
   should say who approved, not copy the customer's details.

2. 2

   Carry the request ID through every workflow

   A run with its request is a record; without it, a log.

   Copy

   Set a request ID at intake and pass it to every workflow the request
   touches, including handoffs to other teams. Store it on the records
   the process creates in other systems too.
   
   If a workflow is started without a request ID, log that as a problem
   to fix, not as a run to ignore.

3. 3

   Land everything in one place

   Each tool's own history disappears on its own schedule.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas. Write the lines to one Snowflake table, in batches
   if the volume is high, and never drop a line because the warehouse
   was briefly unavailable: hold it and retry.
   
   Agree how long the record is kept with whoever owns the process,
   and set it on the table. Check row counts against run counts each
   day, so a gap in the record is found the same week.

4. 4

   Report time and failures by stage

   A slow process is almost always one slow stage.

   Copy

   Build a weekly report by request type: total cycle time, time in
   each stage, how many requests waited for a person and for how long,
   how many failed and at which step, and how many finished with no
   manual step at all.
   
   Make "what happened to this request?" a one-line lookup by request
   ID that returns every step in order, with who decided and when.

5. 5

   Alert when a stage drifts

   The process owner should hear before the requester complains.

   Copy

   For each stage, track its normal time and failure rate over the last
   month. When this week moves well outside that range, post in the
   process owner's Slack channel with the stage, the change and three
   example requests.
   
   Alert on the stage, not on every slow request. One message with the
   pattern is read; fifty single alerts are muted.

6. 6

   Validate it, then hand the report to the owner

   Because the questions change after the first month.

   Copy

   Run the per-step checks and the whole-workflow audit before this goes
   live. Follow three requests end to end, including one that failed and
   one handed to another team, and check every step appears with the
   right request ID.
   
   Then open the same workflow in Tray Build so the process owner can
   add fields, change the stages and set the alert ranges in the visual
   canvas without a deployment.

What it connects to

Every workflow writes to the same record, and the record answers questions about the whole process.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides