Daily Checklist for Running AI Workflows in Production

This checklist is for operations teams running AI workflows in Dave by voolama (hellodave.ai). It is grounded in the shipped product at platform version DEV v0.11.0, with help documentation confirmed against content_orchestrator main at commit ddb945f on 2026-08-30. Every menu path, role name, status badge, and UI label in this checklist reflects what is in the product at that version. If your tenant is running a later version, the structure is the same but specific labels may have changed.

Two honest limitations of the current build, disclosed upfront:

1. Dave by voolama does not currently send push or email alerts when an instance fails or a task times out. Every signal in this checklist is pull-based: you have to open the interface to see it. This is why the daily check matters and why it needs a named owner, not a shared responsibility.
2. The instance list does not currently offer a filter by status. Scanning for red, amber, and pink badges is visual. On high-volume tenants, work through the list systematically from the top.

Who can complete this checklist: you need at minimum the Use role. Use-role users can view the Dashboard, view and control instances, and view and complete tasks in the Task Inbox. The Reporting role can view the Dashboard and instance list but cannot access the Task Inbox (Admin and Use only) or control instances. Dave by voolama has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable by an Admin.

For a full explanation of what each Dashboard card and instance status means, see the companion guide: Run your day from the dashboard. For guidance on diagnosing a specific failing instance, see: What to watch when AI workflows run unattended.

Navigate to the Dashboard from the main navigation. The Dashboard is the home screen of Dave by voolama and loads data when you navigate to it. If counts look stale, refresh the browser page before reading the values. The Dashboard does not auto-refresh.

Read all four summary cards. The key relationship is Running Instances (green) versus Pending Tasks (amber): a high Pending Tasks count relative to Running Instances means human review is the bottleneck and instances are stalling at Human Review or User Interaction nodes.

• Active Agents (blue): is this the number you expect? A drop means an agent has been retired or disabled. Any running workflow that calls a missing agent will fail when it reaches that node. Record the count: ____
• Workflows (purple): is this the number you expect? A change means a workflow definition was added or deleted since yesterday. Record the count: ____
• Running Instances (green): is this in line with expected volume for this time of day? Zero on a day when overnight batch jobs should have started is a signal to investigate immediately. Record the count: ____
• Pending Tasks (amber): is this stable or declining versus yesterday's end-of-day figure? A rising count means tasks are arriving faster than they are being resolved. Record the count: ____
• Running Instances and Pending Tasks relationship assessed. If Pending Tasks is high relative to Running Instances, proceed directly to Section 3 (Task Inbox) before Section 2.

Source: Dashboard help documentation, DEV v0.11.0, confirmed 2026-08-30.

Click the Running Instances card on the Dashboard to navigate to the instance list, or navigate there directly from the sidebar. The instance list displays all instances in your tenant with a colour-coded status badge in the Status column. Dave by voolama defines ten instance statuses; three require action during a daily check.

Failed instances (red badge, status: failed):

• Are there any red badges? A failed instance encountered an unrecoverable error and stopped permanently. It will not retry on its own and cannot be restarted.
• For each failed instance: open the instance detail page. Expand the Context viewer (click Context ▸) and read the error. Check the tasks table for a failed task entry: the Node column identifies which workflow graph node caused the failure.
• Fix the underlying cause. Common causes documented in the product help: an expired or revoked API key (fix: navigate to Admin, then API Management, then Providers, edit the provider, enter a valid key); a misconfigured agent node; or a workflow graph path with no valid exit. After fixing, create a new instance from the same workflow version to rerun the job.

Stuck waiting instances (amber badge: waiting_user_input, or pink badge: waiting_review):

• Are there any amber or pink badges on instances that have been in that state longer than your expected turnaround? These instances are paused at a human decision point and will not proceed until a task is completed. They are not failing.
• For each stuck waiting instance: open the instance detail page, find the pending task in the tasks table, click the Type link to open the task detail page, read the Payload section, and click Approve, Reject, or Request Changes. The instance resumes automatically once the task is submitted.

Unexpectedly long running instances (green badge: running):

• Is any instance in running status for longer than your expected workflow duration? Open the instance detail page and check the tasks table for a task in in_progress status that has not been submitted. An in-progress task that is not moving may indicate the assignee is unavailable.

Current limitation (DEV v0.11.0): the instance list does not offer a status filter. Scanning for red, amber, and pink badges is visual.

Source: Instances help documentation, DEV v0.11.0, confirmed 2026-08-30. Status reference: ten statuses defined, colours sourced from the shipped status reference table.

Navigate to Tasks in the sidebar. The page heading reads Task Inbox. This page is accessible to Admin and Use roles only. Reporting, Create, Curate, and Financial roles cannot access the Task Inbox or view task details.

Use the status filter dropdown in the top-right corner. Select pending to see only tasks actively blocking workflow progress. The Task Inbox displays four columns: Type (links to task detail), Status (colour-coded badge), Instance (truncated ID linking to the parent instance), Assignee (user ID or dash if unassigned), and Due (deadline date or dash if not set).

The four task types you will encounter: user_interaction (requires human input), human_review (requires a review decision), agent_review (AI-generated output for human verification), and safety_check (content flagged for safety review). All four use the same Approve, Reject, Request Changes interface on the task detail page.

Prioritise in this order:

1. Tasks with a Due date of today or earlier: these are at risk of timing out. A timed-out task moves to failed status, which may cause its parent instance to fail. Open each one, read the Payload section, and submit a decision (Approve, Reject, or Request Changes). Add a Comment when rejecting or requesting changes.
2. Tasks with no Due date pending longer than your expected turnaround: check the Assignee field. If it shows a dash (unassigned) or a user who is unavailable, an Admin or Use-role user can complete the task. The workflow instance will not move until the task is resolved.
3. All remaining pending tasks, oldest-first: each resolved task unblocks the workflow instance that generated it.

Task decisions are recorded in the audit trail with the acting user and timestamp. When SOC 2 or GDPR compliance modes are active on your tenant, these events support SOC 2 CC6.1 (logical access controls) and GDPR Article 30 (records of processing activities).

Source: Tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

At the end of the working day, run a shortened version of the check before logging off. The goal is to confirm that no instances are stalling overnight without a named owner who will see them in the morning.

• Return to the Dashboard and refresh the page. Is Pending Tasks lower than it was at the start of the day? If it is higher, tasks are arriving faster than they are being resolved. Note the end-of-day count for the morning reviewer: ____
• Check the instance list for instances that entered waiting_user_input or waiting_review in the last two hours of the working day. These will be waiting overnight. Either resolve the pending task now, or note the instance IDs explicitly for the morning reviewer.
• If your team runs overnight batch workflows: confirm that the expected instances have been created and are in running or draft status. A batch job that failed to start shows no instance at all, not a failed instance. Check the Workflows card count has not changed unexpectedly.
• Confirm the named person responsible for tomorrow's morning check: ____. The daily check must have a named owner. Unowned shared responsibilities are skipped. The audit trail timestamps every state transition, so the morning reviewer can reconstruct overnight events by scanning the instance list for status changes since the previous check, without querying logs or a database.

What is the daily checklist for running AI workflows in production with Dave by voolama?

The daily checklist for Dave by voolama (hellodave.ai) covers four areas in order: the four Dashboard summary cards (Active Agents, Workflows, Running Instances, Pending Tasks), the instance status list scanned for red failed badges and amber or pink stuck-waiting badges, the Task Inbox filtered to pending tasks and prioritised by due date, and an end-of-day confirmation that no instances are stalling overnight without a named reviewer. The check takes under five minutes on a healthy tenant. Dave by voolama does not currently send push or email alerts on failure, making this pull-based daily check the primary mechanism for catching problems early. Grounded in DEV v0.11.0, confirmed 2026-08-30.

Which DAVE roles can complete the daily operations checklist?

You need at minimum the Use role to complete the full checklist in Dave by voolama. Use-role users can view the Dashboard, view and control instances (start, pause, resume, cancel), and view and complete tasks in the Task Inbox. The Reporting role can view the Dashboard and instance list but cannot access the Task Inbox or control instances. Dave by voolama has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable rows in the database, so a tenant Admin can adjust permissions.

What should I do when I find a failed instance during the daily check?

Open the instance detail page in Dave by voolama, expand the Context viewer (click Context ▸), and read the error message. Check the tasks table for a failed task entry: the Node column identifies which workflow graph node caused the failure. Fix the underlying cause, for example updating an expired API key under Admin, then API Management, then Providers. Then create a new instance from the same workflow version to rerun the job. Failed instances cannot be restarted: a new instance is always required.

What is the difference between a failed instance and a stuck waiting instance in DAVE?

A failed instance (red badge, status failed) in Dave by voolama encountered an unrecoverable error and stopped permanently. It needs investigation and a new instance to rerun. A stuck waiting instance (amber waiting_user_input or pink waiting_review badge) is paused at a human decision point and will resume automatically once the pending task in its tasks table is completed. Stuck waiting instances are not failing: they are waiting for a person to act.

How do I prioritise tasks in the Task Inbox during the daily check?

In the Dave by voolama Task Inbox, prioritise in this order: first, tasks with a Due date of today or earlier (at risk of timing out and moving to failed status); second, tasks with no Due date that have been pending longer than your team's expected turnaround; third, all remaining pending tasks oldest-first. Use the status filter dropdown in the top-right corner of the Task Inbox and select pending to see only actionable tasks.