Delete a Run

Maintain organized training projects with periodic cleanup:

Weekly review:

• Delete obvious test runs and accidental starts
• Remove failed runs after fixing issues and retraining
• Clean up superseded runs from iteration cycles

Monthly audit:

• Review all completed runs older than 30 days
• Delete experimental runs no longer needed
• Archive critical runs by downloading models
• Update project documentation with important findings

After major milestones:

• Clean up all runs after successful model deployment
• Remove iterative experiments that led to final model
• Keep only final successful run and key baselines

Benefits:

• Easier to find important runs quickly
• Clearer project history and progress tracking
• Reduced cognitive load when reviewing experiments

Always export important artifacts before deletion:

Checklist:

1. Trained models:

   • Download model files for deployment
   • Save with descriptive names indicating configuration
   • Store in version control or model registry

2. Metrics and results:

   • Screenshot final evaluation metrics
   • Export loss charts and training curves (if available)
   • Record final accuracy, F1, or other key scores

3. Configuration details:

   • Document workflow settings used
   • Note dataset configuration and splits
   • Record model architecture and parameters
   • Save system prompt text

4. Lessons learned:

   • Note what worked well or poorly
   • Document issues encountered and solutions
   • Record insights for future training

Prevention: Create systematic export workflow before any deletion to avoid losing valuable data.

Use clear workflow names to make deletion decisions easier:

Good examples:

• PCB-Detection-Baseline-v1 — Clear purpose and version
• Defect-VQA-Test-SmallDataset — Indicates experimental nature
• Quality-Inspection-Production-Final — Shows production status

Poor examples:

• New Workflow — Unclear purpose
• Test — Doesn't indicate what was tested
• Run 1 — No context about configuration

Benefits:

• Easy to identify runs safe to delete
• Understand run purpose without opening details
• Team members can make informed cleanup decisions

When deleting multiple runs, use systematic approach:

Preparation:

1. List all runs in project
2. Categorize: Keep, Archive (download), Delete
3. Download models from "Archive" category
4. Verify downloads successful

Execution:

1. Start with oldest runs first
2. Delete from least to most critical (in case interrupted)
3. Keep running tally of deleted vs. kept runs
4. Verify deletions complete before moving to next

Documentation:

1. Note why specific runs were deleted
2. Record what models were archived
3. Update project documentation reflecting current state

Efficiency tips:

• Group similar runs for batch review
• Use status filters to find failed runs quickly
• Sort by date to identify old runs easily

For shared training projects, coordinate deletion with team:

Before deleting shared runs:

1. Announce planned cleanup via team chat or meeting
2. Share list of runs you plan to delete
3. Allow review period for team to flag important runs
4. Confirm no objections before proceeding

Communication channels:

• Team messaging platforms (Slack, Teams, etc.)
• Project management tools
• Shared documentation or wikis
• Weekly team sync meetings

Prevention:

• Establish team policy on when runs can be deleted
• Define ownership for different workflows
• Use naming conventions to indicate run importance
• Document cleanup responsibilities

No. Training run deletion is permanent and irreversible.

There is no:

• Undo functionality
• Trash bin or recycle bin
• Backup or restore mechanism
• Recovery period or grace window
• Support recovery process

Once deleted, permanently lost:

• Trained model weights and checkpoints
• Training metrics and loss curves
• Detailed logs and debugging information
• Run configuration and metadata
• Progress history and timestamps

Best practice: Always download models and export important metrics before deletion. Take screenshots of key information you might need later.

Prevention:

• Double-check run identity before confirming deletion
• Download models immediately after successful training
• Maintain local archives of important models
• Use caution when performing bulk cleanup

Models are permanently deleted along with the run. They cannot be recovered.

If model not downloaded:

• Model is permanently lost
• Cannot be recovered by support
• Must retrain to recreate model

If model was downloaded before deletion:

• Downloaded model files remain on your computer
• Can still deploy or use the model
• Model operates independently of Datature platform

Deployment implications:

External deployments (recommended):

• Models downloaded and deployed externally continue working
• Run deletion doesn't affect already-deployed models
• Model operates independently as standalone file

Platform-linked deployments:

• Direct references to run models may break
• Best practice: deploy using downloaded model files
• Update deployments to use exported models

Prevention: Always download models immediately after successful training, before any deletion.

No. Deleting training runs does not refund Compute Credits.

What happens:

• Credits consumed by completed training remain spent
• Past run costs stay in usage history
• Deletion doesn't affect current credit balance
• Future training consumes credits normally

Credits are consumed when:

• Training runs execute on GPU hardware
• Regardless of whether runs are later deleted
• Based on actual GPU time used during training

Credit management:

• Monitor runs actively to catch issues early
• Kill failing runs quickly to minimize waste
• Test configurations with short training before full runs
• Review resource usage regularly

Run deletion purpose:

• Organize project and clean up history
• Remove clutter from runs list
• Free up visual space in UI
• Not for recovering consumed credits

Currently, training runs must be deleted one at a time through the web interface. There is no bulk delete functionality.

To delete multiple runs:

1. Navigate to the Runs tab
2. For each run you want to delete:
   • Click the three-dot menu (⋮)
   • Select Delete Run
   • Confirm the deletion
3. Repeat for each run

Workflow optimization:

Batch deletion session:

1. Prepare list of runs to delete
2. Download models from runs needing preservation
3. Block time for systematic deletion
4. Work through list one by one
5. Document progress to track completion

Efficiency tips:

• Use run filters to show only failed runs or specific statuses
• Sort by date to find oldest runs easily
• Start with least critical runs first
• Take breaks during large cleanup sessions

Feature request: If bulk deletion would help your workflow, consider submitting feedback to the Datature team.

No automatic notification is sent to team members. For shared projects:

Before deletion:

1. Inform your team about planned deletions
2. Share list of runs you intend to remove
3. Allow review period for team to flag important runs
4. Confirm no blockers from team members

Communication methods:

• Team chat or collaboration tools
• Project management systems
• Email to team members
• Team standup or sync meetings

Best practice for shared projects:

Establish deletion policy:

• Who can delete runs (all members, leads only, etc.)
• Required notice period before deletion
• Documentation requirements
• Approval process for production run deletion

Maintain transparency:

• Post cleanup schedules in team channels
• Share reasons for deletions
• Update shared documentation
• Keep team informed of project state changes

You can filter runs by status to focus on failed runs:

Access failed runs:

1. Navigate to the Runs tab in your training project
2. Use status filters (if available) to show only "Failed" runs
3. Review the list of failed runs
4. Delete individual failed runs as needed

Systematic cleanup:

Weekly failed run review:

1. Check logs to understand failure reasons
2. Document fixes applied to prevent recurrence
3. Delete runs after issues resolved and successful retraining completed
4. Keep one example of each failure type for reference

When to keep failed runs:

• Reference examples — Demonstrate specific failure patterns
• Under investigation — Still debugging root cause
• Recent failures — Within last few days, haven't retrained yet
• Team review pending — Waiting for team analysis

When to delete failed runs:

• Issue resolved — Problem fixed and successful run completed
• Old failures — From weeks/months ago, no longer relevant
• Obvious mistakes — Clear configuration errors, not informative
• Duplicates — Multiple runs with same failure

Currently, there is no "export all run data" feature. You must manually save components:

What you can export:

1. Trained models:

• Download model files for completed runs
• Save with descriptive filenames
• Store in organized directory structure

2. Metrics (manual export):

• Screenshot loss charts and evaluation metrics
• Copy final metric values to spreadsheet or notes
• Export chart images if platform allows
• Record in experiment tracking system

3. Configuration (manual documentation):

• Document workflow settings used
• Screenshot or copy system prompt text
• Note dataset splits and parameters
• Record model architecture details

4. Logs (view and copy):

• View detailed logs in platform
• Copy relevant log sections to text files
• Screenshot error messages or important output
• Save debugging information locally

Recommended workflow:

Create run archive folder:

project-name/
├── models/
│   ├── run-001-baseline-model.pth
│   └── run-015-optimized-model.pth
├── metrics/
│   ├── run-001-results.png
│   └── run-015-results.csv
├── configs/
│   ├── run-001-config.txt
│   └── run-015-config.txt
└── logs/
    ├── run-001-errors.log
    └── run-015-training.log

Best practice: Establish export workflow early in project to maintain consistent archives before deletion.

Unfortunately, deletion is permanent and irreversible.

No recovery options:

• Cannot restore through support
• No server-side backups available
• No undo or rollback functionality
• No trash bin or recycle bin

Your only options:

1. Use local backups (if you have them):

• Reinstall downloaded model if you saved it
• Reference exported metrics and screenshots
• Review saved logs and configurations

2. Retrain from scratch (if no backups exist):

• Create or reuse workflow with same settings
• Start new training run to recreate model
• Replicate original configuration as closely as possible
• Monitor new run to ensure matches expected behavior

3. Accept the loss (if critical data lost):

• Training history permanently gone
• Model must be retrained if not backed up
• Metrics cannot be recovered
• Learn from experience for future prevention

Prevention measures:

Immediate actions:

• Download all successful models right after training completes
• Export key metrics before any deletion
• Verify run identity before confirming deletion
• Double-check run name in confirmation dialog

Long-term practices:

• Establish automatic model download workflow
• Use descriptive naming to avoid confusion
• Implement team approval for production run deletion
• Maintain systematic archive of important experiments
• Document deletion decisions and reasoning

Before clicking Confirm:

• Read confirmation message carefully
• Verify run name matches intended deletion
• Check run start time to confirm identity
• Ensure any needed data already exported