1. Check installation
2. Check the effective workspace
DEEPLINE_API_KEY into your shell.
A raw HTTP caller needs its own supported server-side credential setup.
Do not print keys into logs to diagnose this difference.
3. Separate discovery from input errors
deepline plays check <file>.
For CSV failures, use file validation.
Do not build a retry sample by splitting physical lines with head.
4. Inspect existing work
For a Play, inspect the saved run:5. Reconcile usage separately
6. Diagnose connections and external writes
A provider 401 or 403 indicates an access problem, not an empty dataset. Check the intended workspace connection and the selected action’s requirements. Only owners and admins can connect integrations through the supported flow. A write timeout can leave an uncertain destination outcome. Read and reconcile that state before repeating the mutation. A successful connection does not prove that every property update is allowed. Use Integrations, CRM repair, and Production integration for the specific path.7. Diagnose Database access
A successful empty query means no returned matches under that query. A permission error means the statement did not establish those data facts. Use Query Database for permitted customer SQL. Customer-owned tables and Deepline-managed views have different write rules. A direct Postgres integration uses its own connected database and permissions.8. Prepare a useful report
Record the expected result, observed result, operation, and exact error. Keep the relevant run or execution identity for a targeted follow-up. Exclude credentials and unrelated customer records.The report identifies the failed boundary and whether work may already exist.
It does not substitute an empty result, zero charge, or a fresh run for
uncertainty.