What is the primary goal of model validation after deployment in Domino?

The primary goal is to prevent **inefficient, incorrect, or unused models** in production. Validation ensures the model returns expected results, consumes optimal resources, and is actively serving traffic, thus avoiding slow, costly, or broken endpoints.

What are the key metrics monitored during model validation in Domino?

The core metrics you should monitor are **endpoint responses** (to confirm correctness), **CPU and memory usage** (to ensure resource efficiency), **request success and error rates** (for reliability), and **traffic volume** (to confirm actual utilization).

When is the best time to use this validation approach?

This approach should be used at three key times: during **initial deployment** to confirm correct behavior, **during development** to test and optimize code efficiency, and **after deployment** to verify utilization and provide evidence of correct operation in production.

How does monitoring traffic metrics confirm production readiness?

Monitoring traffic metrics proves whether your model is **actually being called** by downstream applications or users. A model using compute resources but receiving no requests indicates a **“silent failure,”** meaning the model is deployed but is not being utilized.

How to monitor and optimize endpoints in Domino

Overview and goals

Domino makes it easy for data scientists to deploy endpoints, but deployment is only part of the job. Without validation, models risk being inefficient, returning incorrect results, or not being used in production at all.

This blueprint helps you:

Validate endpoint responses during development.
Monitor CPU, memory, and error rates as you test.
Confirm your endpoints are actually serving traffic after deployment.

By checking these metrics early and often, you’ll avoid shipping slow, costly, or broken endpoints.

When should you consider using this approach?

When you first deploy an endpoint and want to confirm correct behavior.
During development, to test efficiency and optimize code before handing off.
After deployment, to check utilization and provide evidence that your model is running correctly in production.

Why does data-driven mode performance optimization help you achieve the above goals?

Direct validation: You see real request/response pairs to confirm correctness.
Resource efficiency: CPU and memory charts show whether your model is consuming excessive resources.
Production confirmation: Traffic metrics prove whether your model is actually used, preventing “silent failures” where a model is deployed but never called.

How to do model validation in Domino

Step 1. Deploy your model endpoint and validate responses

Navigate to Endpoints → [Your Endpoint] → Versions.
Send a test request using the Domino UI, curl, or a Python client.

Python

#!/usr/bin/env python3
"""
Quick Test Script for Domino Model Endpoints
Copy and paste this script to test your model and observe metrics in Domino
"""


import requests
import time


# Replace with your Domino model endpoint URL
ENDPOINT_URL = "https://your-domino-instance.com/models/your-model-id/latest/model"


# Replace with your Domino API key (same value for both username and password)
API_KEY = "your-domino-api-key-here"


def test_model():
   """Test the model endpoint and measure response time"""
  
   # Sample request data - adjust based on your model's expected input
   data = {
       'data': {
           'start': 10,
           'stop': 90
       }
   }
  
   headers = {'Content-Type': 'application/json'}
  
   print(f"Testing endpoint: {ENDPOINT_URL}")
   print("Sending request...")
  
   start_time = time.time()
  
   try:
       response = requests.post(
           ENDPOINT_URL,
           json=data,
           auth=(API_KEY, API_KEY),  # Domino uses API key for both username and password
           headers=headers,
           timeout=30
       )
      
       response_time = time.time() - start_time
      
       print(f"Status Code: {response.status_code}")
       print(f"Response Time: {response_time:.3f} seconds")
      
       if response.status_code == 200:
           result = response.json()
           print("✅ Success!")
           print(f"Response: {result}")
       else:
           print("❌ Error!")
           print(f"Error: {response.text}")
          
   except Exception as e:
       print(f"🔥 Connection Error: {str(e)}")


if __name__ == "__main__":
   print("🎯 Quick Domino Model Test")
   print("=" * 40)
   test_model()
   print("\n💡 Check your Domino dashboard for CPU, memory, and HTTP metrics!")

Confirm the endpoint returns the expected output for known inputs.

Step 2: Monitor CPU, memory, and traffic during development

Domino provides real-time usage charts directly in the endpoint version page. These charts let you quickly spot inefficiencies and validate improvements by switching between versions:

CPU usage: Look for consistent patterns. If one version shows noticeably higher CPU load than another, that’s a sign of inefficient code or resource pressure.
Memory usage: Healthy models stabilize after initialization. If memory keeps climbing or fluctuates heavily across requests, you may need to revisit how your model handles data.
Traffic metrics: Verify that your test requests are being recorded. Missing traffic usually points to wiring or deployment issues.

By switching between versions, you can easily confirm whether new code changes improved efficiency or introduced regressions. For example, if Version 2 shows CPU spikes or memory growth compared to Version 1 as you clearly see above, you know where to focus optimization.

Step 3: Review request success and error rates

Every request generates a status code, which gives you immediate feedback on reliability. The status code distribution panel lets you compare patterns across versions:

2xx = success → Confirms predictions are returned correctly.
4xx = client errors → Often point to input or validation issues.
5xx = server errors → Indicate failures inside the model or its environment.

If errors increase after a new deployment, it’s a signal that the change introduced instability. If errors decrease, you’ve validated that your fix worked. This gives you confidence that the model is production-ready.