Skip to main content
The first five to seven days after an assignment goes live are the highest-risk period. Volume is real, edge cases you did not test for will surface, and small problems compound quickly if you are not watching. This guide gives you a daily review cadence, the specific signals to track in Duvo, and a clear playbook for the most common anomalies — so you can tell the difference between normal early noise and something that genuinely needs your attention.

​
Why the First Week Is Different

During testing you controlled the inputs. In production, inputs are unpredictable — real emails, real files, real volumes. Assignments that worked perfectly in tests often surface new failure modes in the first week simply because the variety of real-world data is much wider than your test cases covered. The goal of first-week monitoring is not to watch every Job in real time. It is to catch pattern changes early enough to act before they become problems, and to graduate off intensive monitoring once you have evidence that the assignment is stable.

​
Daily Checks: Day 1 to Day 7

Run through this list each day while the assignment is in its first week of production use. It takes about five to ten minutes.

​
Activity Inbox

Open the Activity Inbox and check for pending approval requests.
  • Are there more pending requests than expected? A spike in Needs Input usually means the SOP is hitting an ambiguous case it is not confident about — see Spike in Needs Input below.
  • Are requests sitting unanswered for more than a few hours? Unanswered requests pause the Jobs that created them. If your team is not seeing the notifications, adjust the escalation path in the SOP or your Slack/email notification setup.

​
Case Queue health (if applicable)

If the assignment uses Case Queue, open the Cases view and check the status breakdown for the time period covering the last 24 hours.
MetricHealthy rangeWatch for
Failed rateUnder 5% of cases processedAny sudden spike above your baseline
Needs Input rateStable or declining over the weekRising rate signals a SOP gap
Postponed rateStableRising rate may indicate an upstream system is slow

​
Jobs List

Open the Jobs List (Past Jobs) and apply the Needs attention filter to see any Failed or Needs Input Jobs from the past 24 hours.
  • For each failed Job, open it and note which step failed. Look for clustering: if five Jobs all fail at the same step, that is a SOP or Connection issue, not random noise.
  • If a Job failed due to a Connection error, go to Connections, check whether the Connection is still authorized, and re-authorize if needed.

​
Cost per Job trend

In Team Insights, check the average cost per run for this assignment over the past 24 hours against your baseline from testing.
  • A cost spike often means the assignment is making more tool calls than expected — common when the SOP does not give the assignment a clear stopping point and it keeps searching or retrying.
  • A cost spike can also indicate a tool-call loop: the assignment calls a tool, gets an unexpected result, and tries again repeatedly. Open the high-cost Job from the Jobs List and scroll through the steps to find where calls are repeating.

​
Output spot-check

Pick three to five completed Jobs at random and open them. Read the output the assignment produced.
  • Does the output look correct? Would a human reviewer accept it?
  • Are there patterns in what looks off? Edge cases cluster — if you find one, look for others like it.

​
Team Insights Signals to Watch

Open Team Insights and set the time period to Last 7 days. Use these signals to identify trends early.

​
Run volume vs expected

Compare the number of Jobs triggered against what you expected when you set up the schedule or trigger.
  • Significantly fewer Jobs than expected may mean the trigger is not firing (check the trigger configuration) or Jobs are failing before they complete (check the Failed count).
  • Significantly more Jobs than expected may mean the trigger is firing on events you did not intend. Check the trigger source configuration and consider adding a filter in the SOP.

​
Source breakdown

The source breakdown shows where runs originate — manual, scheduled, or from a specific trigger.
  • If the source mix changes unexpectedly (for example, a scheduled assignment suddenly shows a spike in manual runs), investigate whether team members are retriggering Jobs manually because they do not trust the automatic output.

​
Failure clusters

If the failure rate is above your baseline, look for clustering before making SOP changes.
  • Single Connection failing repeatedly: the external service may be experiencing issues, or the Connection credentials expired. Check the third-party service status page and re-authorize the Connection if needed.
  • Failures spread across multiple Connections: this usually points to a SOP logic issue — the assignment is attempting something in the wrong order or with the wrong data.
  • Failures only on certain input types: your SOP needs to handle that input shape. Add a HITL gate to catch it while you refine the SOP.

​
HITL approval rate by branch

If the assignment has multiple approval gates, check whether one is generating significantly more requests than others. A single gate driving most of the Needs Input volume is usually the first SOP gap to fix.

​
Anomaly Response Patterns

​
Spike in Needs Input

What it means: The assignment is frequently reaching a decision point it is not confident about. It is asking for help rather than deciding autonomously. How to respond:
  1. Open several recent Needs Input requests in the Activity Inbox and read them carefully.
  2. Identify what they have in common — the same type of question, the same step in the workflow, the same data condition.
  3. Update the SOP to handle that condition explicitly. Either give the assignment a rule to follow, or widen the HITL gate with a clearer decision framework so reviewers can respond consistently.
  4. If the condition genuinely should always require human approval, tighten the HITL gate description so reviewers understand what they are approving.

​
Spike in Failed Jobs

What it means: Jobs are ending without completing successfully. This requires immediate investigation. How to respond:
  1. Open two or three failed Jobs from the Jobs List (Past Jobs in the sidebar) and read through the steps of each one to find where it failed.
  2. If they all fail at the same step, that step has a problem — a Connection issue, a data format mismatch, or a logic error in the SOP.
  3. If they fail at different steps, look for a common thread: the same Connection, the same input type, or the same time of day (which may indicate an external service outage).
  4. If the failure rate is high and you cannot immediately fix the root cause, consider pausing the assignment (disable the schedule or trigger) and communicating to your team while you investigate.

​
Cost spike

What it means: Individual Jobs are consuming significantly more than your baseline cost estimate. How to respond:
  1. Open one of the high-cost Jobs from the Jobs List and scroll through the steps.
  2. Count how many tool calls the assignment made. A healthy Job typically makes a predictable number of calls. A high-cost Job often shows many repeated calls to the same tool — a sign of a loop.
  3. If you see a tool-call loop, update the SOP to give the assignment a clear exit condition. For example: “If you do not find the record after searching twice, stop and request HITL.”
  4. If the cost is high but the tool calls look reasonable, the inputs may be much larger than expected. Check whether you can batch the input or pre-filter it before the assignment processes it.

​
Latency drift

What it means: Jobs are taking significantly longer to complete than during testing. How to respond:
  1. Check whether the latency drift is consistent across all Jobs or isolated to specific runs.
  2. If isolated, the upstream system may have been slow at that time (check external service status pages or your own infrastructure logs).
  3. If consistent, compare the volume of data the assignment is processing in production versus testing. Real-world volumes are often larger. Update the SOP to process in smaller batches, or add a volume cap while you investigate.
  4. If Job duration is approaching your business process SLA, consider whether you need to adjust the schedule (run more frequently in smaller batches) or add a volume limit to the SOP.

​
Emergency Stop

If something is clearly going wrong and you need to stop the assignment immediately: Disable the schedule or trigger
  1. Open the assignment.
  2. Click the Schedule button in the assignment header.
  3. Toggle the schedule off, or navigate to the Triggers tab and disable the trigger.
  4. Jobs already running will complete. No new Jobs will start.
Revoke a connection (fastest stop for write-heavy assignments) If the assignment is actively writing data and you need to stop it mid-run:
  1. Go to Connections in the left sidebar.
  2. Find the Connection the assignment is using to write data.
  3. Disconnect it.
The assignment fails immediately when it tries to use that Connection. This is the fastest way to stop a write-heavy assignment when you are not sure whether damage is still occurring. Revert to a previous version If the problem was introduced by a recent SOP change:
  1. Open the assignment.
  2. Use the revision selector in the builder toolbar to select the last known-good revision.
  3. Switch back to that version and re-enable the schedule or trigger.
  4. Monitor the next two or three Jobs manually before reducing your check frequency.
See Assignment Versions for details on browsing and restoring revisions.

​
Post-Incident Template

When something goes wrong and you need to communicate or document it, use this template. To identify the root cause before filling it in: open one of the failed Jobs from the Jobs List and read the step where it failed. A Connection error points to a credential issue. Repeated failures on the same step with similar inputs point to a SOP logic gap. A failure on the very first step often means the input data was missing or malformed. 
Date: [date]
Assignment: [name]
Owner: [name]

What happened:
[One paragraph: what the assignment did, what it should have done, and what the impact was.]

How we detected it:
[Daily check / alert / team member reported / ...]

Root cause:
[What specifically caused the failure — e.g.:
 - SOP gap: the assignment hit a case the SOP did not handle
 - Connection issue: a Connection was disconnected or its credentials expired
 - Input data issue: the data passed to the assignment was missing or malformed
 - External service outage: the third-party service was unavailable]

What we changed:
[SOP update / Connection fix / volume cap added / ...]

What we will watch:
[The specific metric or signal we will monitor over the next [N] days to confirm the fix worked.]

​
Graduating Off First-Week Mode

You can move from daily checks to a routine operational rhythm when all of the following are true for three consecutive days:
  • Failed rate is under 5% and stable or declining.
  • Needs Input rate is stable or declining.
  • No cost or latency spikes.
  • Output spot-checks look correct.
  • No unresolved anomalies in the Activity Inbox.

​
Handoff to ongoing operational rhythm

When you graduate off first-week monitoring:
  1. Move to weekly rather than daily checks, using Team Insights to review the past seven days.
  2. Set up persistent alerts if your assignment uses a notification step in the SOP — for example, a Slack message after each run summarizing the outcome.
  3. Schedule a 30-day review with the assignment owner to reassess whether the SOP needs refinement based on accumulated production experience.
  4. Update the assignment runbook with anything you learned in the first week — owner contact, typical cost per Job, known edge cases, and the escalation path.