Monitor a Flask App with Datadog APM

Instrument a Flask app with Datadog to track errors, set alerts, and resolve incidents.

Introduction

30 Second Summary

Every time you open an app and it just works, there is a team behind the scenes watching for errors, traffic spikes, and slow responses. They catch problems before users notice because their apps are wired to monitoring tools that alert them the moment something goes wrong.

In this project, you will build a small web server, connect it to Datadog for real-time monitoring, and simulate a production incident. You will trigger alerts, investigate errors, and resolve the incident using real observability tooling.

What You'll Build

A Flask API monitored end-to-end by Datadog, with automatic tracing, error capture, and a throughput alert you trigger and resolve yourself.

By the end of this project, you'll have:

  • A running Flask app instrumented with Datadog's ddtrace library, sending traces and errors to Datadog APM.
  • A metric monitor configured to alert when request throughput exceeds a threshold.
  • A completed incident investigation workflow where you trigger an alert, dig into the data, and resolve it.
  • Secret Mission: Add a custom span that tracks a simulated database query and create a latency-based monitor that alerts when it runs too slow.

Are there any prerequisites?

You need a Mac with Python 3 already installed. This project walks you through setting up everything else, including your Datadog account, the Datadog Agent, and all Python packages.

Set Up Datadog Account and Agent

Before you can monitor any application, you need a place to send the data. Datadog is a cloud observability platform that collects metrics, traces, and errors from your apps and displays them in one dashboard.

To get data from your Mac into Datadog's cloud, you need the Datadog Agent running locally. In this step, you'll create a Datadog account, grab your API key, and install the Agent.

In this step, get ready to:
  • Sign up for a Datadog free trial.
  • Retrieve your API key.
  • Install and verify the Datadog Agent on macOS.
Sign up for Datadog and retrieve your API key

The Datadog Agent needs an API key to authenticate with Datadog's servers. You'll create a free trial account and copy the key.

  • Open your browser and navigate to https://www.datadoghq.com/free-datadog-trial/.
  • Fill in your name, email, company name, and password, then click Sign Up.
  • Choose your region (the default US region works fine) and complete any onboarding prompts.
  • Once you land on the Datadog dashboard, click your account avatar in the bottom-left corner of the sidebar.
  • Click Organization Settings.
  • Click the API Keys tab.
  • You should see a default API key already created for your organization. Click it to reveal the full key value and copy it somewhere safe (a notes app or sticky note).

What is an API key?

An API key is a unique string that identifies your organization when sending data to Datadog. The Agent uses this key to authenticate every payload it sends to the cloud platform.

Keep this key private

Treat your API key like a password. Do not share it publicly or commit it to version control. For this project you only need it during the Agent install step, which handles it for you automatically.

Install the Datadog Agent via Fleet Automation

The Datadog Agent is a lightweight process that runs on your Mac and forwards data to Datadog's servers. You'll install it using the guided workflow in Datadog's UI.

  • In your Datadog dashboard, click Fleet Automation in the left sidebar (under Infrastructure).
  • Datadog will display an install script pre-filled with your API key and site region.
  • Press Cmd+Space to open your search bar.
  • Type Terminal and press Enter to open it.
  • Copy the install script from the Datadog UI and paste it into your Terminal, then press Enter.
  • Terminal will ask for your Mac password (the one you use to log in). Type it and press Enter. You will not see characters appear as you type your password.

What does the install script do?

The script downloads the Datadog Agent, installs it to /opt/datadog-agent, and writes your API key into its configuration file. It also starts the Agent as a background service so it runs automatically.

The installation takes a minute or two. Wait until you see output indicating the Agent has started successfully.

Install script not showing in Fleet Automation?

Make sure you completed the Datadog signup and are logged into your account. Fleet Automation generates the install command based on your organization's API key and site.

If you cannot find Fleet Automation in the sidebar, try searching for it using the search bar at the top of the Datadog UI.

Help me find the Agent install script in Datadog

Verify the Agent is running

Once the install finishes, you need to confirm the Agent is connected to Datadog and sending data.

  • Check the Agent status by running this command in Terminal:
sudo datadog-agent status
  • Enter your Mac password when prompted.

What should I see?

A long status report prints to your Terminal. Look for a section near the top that shows your Agent version, the API key (masked), and a confirmation that the Agent is connected to Datadog's intake servers. The key line to look for is your API key ending displayed as something like API Key ending with: ****abcd (your last 4 characters will differ).

✔️ I see a status report with my API key

Your Agent is installed and connected. You're ready to move on.

ⓧ I see 'command not found'

The Agent binary might not be in your path. Try running the full path instead:

sudo /opt/datadog-agent/bin/agent status

If this still fails, the install may not have completed. Re-run the install script from Fleet Automation.

ⓧ I see a connection error

The Agent installed but cannot reach Datadog's servers. Check that your Mac is connected to the internet and try restarting the Agent:

sudo launchctl kickstart -k system/com.datadoghq.agent

Wait 10 seconds, then run sudo datadog-agent status again.

Help me troubleshoot my Datadog Agent connection

Your Datadog account is live and the Agent is reporting home. Next up, you'll build a Flask app and connect it to Datadog so you can see real application traces flowing in.

Build and Instrument Your Flask App

Your Datadog Agent is installed and reporting to the cloud. Now it's time to give it something to monitor.

In this step, you'll build a small Flask web server and connect it to Datadog using a library called ddtrace. This library automatically captures every request your app handles and sends that data to Datadog as traces.

In this step, get ready to:
  • Create a project directory and install dependencies.
  • Write a Flask app with three endpoints.
  • Run the app with Datadog tracing enabled and verify traces appear.
Create your project and install dependencies

You need a dedicated folder for your project and a Python virtual environment to keep your dependencies isolated from other Python projects on your machine.

  • Move to your Desktop by running this command:
cd ~/Desktop
  • Create your project folder and move into it by running these commands:
mkdir datadog-flask-app
cd datadog-flask-app
  • Confirm the folder exists by running:
ls

You should see the datadog-flask-app folder listed in the output.

  • Create a Python virtual environment by running:
python3 -m venv venv
  • Activate the virtual environment by running:
source venv/bin/activate

Your terminal prompt should now show (venv) at the beginning, confirming the virtual environment is active.

  • Install Flask and ddtrace by running:
pip install flask ddtrace
  • Confirm the packages installed by running:
pip list | grep -i -E "flask|ddtrace"

You should see both Flask and ddtrace listed with version numbers in the output.

What is ddtrace?

ddtrace is Datadog's Python tracing library. It automatically instruments popular frameworks like Flask so that every incoming request generates a trace. Those traces get sent to the local Datadog Agent, which forwards them to the Datadog cloud platform.

Install failed or command not found?

Make sure your virtual environment is active. You should see (venv) in your terminal prompt. If not, run source venv/bin/activate again.

If python3 is not found, confirm Python 3 is installed on your system by searching for it in Spotlight.

Help me troubleshoot my pip install

Write your Flask app

Your app needs three endpoints: one that succeeds, one that throws an error, and one that simulates real processing work. This gives Datadog a mix of healthy and unhealthy traffic to display.

  • Create a file called app.py in your datadog-flask-app folder. Open it in your code editor and paste in the following code:
from flask import Flask, jsonify
import time
import random

app = Flask(__name__)


@app.route("/")
def home():
    # Success endpoint - returns a simple JSON greeting
    return jsonify({"status": "ok", "message": "Hello from my-flask-app!"})


@app.route("/error")
def error_endpoint():
    # Intentionally raises an exception so Datadog can capture it
    raise ValueError("Something went wrong! This is a simulated application error.")


@app.route("/work")
def work():
    # Simulates variable processing time between 0.1 and 0.5 seconds
    duration = random.uniform(0.1, 0.5)
    time.sleep(duration)
    return jsonify({"status": "completed", "duration_seconds": round(duration, 3)})


@app.errorhandler(ValueError)
def handle_value_error(e):
    # Catches ValueErrors and returns a 500 JSON response
    return jsonify({"error": str(e)}), 500


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5050)

What does this code do?

  • The / endpoint returns a JSON success message. This is your healthy baseline traffic.
  • The /error endpoint raises a ValueError on purpose. Datadog will capture this as an error span with a full stack trace.
  • The /work endpoint sleeps for a random duration (0.1 to 0.5 seconds) to simulate real processing. This creates realistic latency data in Datadog.
  • The error handler catches ValueError exceptions and returns a clean JSON error response with a 500 status code.
  • Port 5050 avoids a conflict with macOS AirPlay Receiver, which uses port 5000 by default.
  • Save app.py.

✔️ Awesome, I've got everything!

Great. Double check you've saved your file before moving on.

ⓧ I'd like to double check the full code

from flask import Flask, jsonify
import time
import random

app = Flask(__name__)


@app.route("/")
def home():
    return jsonify({"status": "ok", "message": "Hello from my-flask-app!"})


@app.route("/error")
def error_endpoint():
    raise ValueError("Something went wrong! This is a simulated application error.")


@app.route("/work")
def work():
    duration = random.uniform(0.1, 0.5)
    time.sleep(duration)
    return jsonify({"status": "completed", "duration_seconds": round(duration, 3)})


@app.errorhandler(ValueError)
def handle_value_error(e):
    return jsonify({"error": str(e)}), 500


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5050)
Run the app with Datadog tracing

Instead of running your app with plain python app.py, you'll use ddtrace-run to wrap the process. This automatically instruments Flask so every incoming request generates a trace sent to your local Datadog Agent.

  • Start your Flask app with tracing enabled by running:
DD_SERVICE=my-flask-app DD_ENV=dev ddtrace-run python app.py

What does this command do?

  • DD_SERVICE=my-flask-app sets the service name that appears in Datadog. This is how you identify your app in the APM dashboard.
  • DD_ENV=dev tags all traces with the environment name dev. Teams use this to separate production from development data.
  • ddtrace-run wraps your Python process and auto-instruments Flask. It sends spans to the Datadog Agent on localhost:8126 (the Agent's default APM receiver port).

You should see output including a line like * Running on http://0.0.0.0:5050. This confirms Flask is serving requests.

  • Open a second Terminal window by pressing Cmd+N in Terminal.
  • Navigate to your project folder and activate the virtual environment by running:
cd ~/Desktop/datadog-flask-app
source venv/bin/activate
  • Send a test request to your app by running:
curl http://127.0.0.1:5050/

You should see the JSON response: {"message":"Hello from my-flask-app!","status":"ok"}.

  • Switch to your browser and navigate to APM in the left sidebar.
  • Click Traces.

What should I see?

After a few seconds, you should see a trace for the my-flask-app service with a resource name like GET /. It may take up to 30 seconds for the first trace to appear.

If you don't see anything yet, send a few more requests with curl and refresh the page.

No traces showing up?

Make sure the Datadog Agent is still running. In a new terminal, run sudo datadog-agent status and look for a successful connection.

Check that your Flask app started without errors. The terminal running ddtrace-run should show the Running on line with no tracebacks above it.

Help me debug why traces aren't appearing

Your app is live and Datadog is watching every request. Next up, you'll generate errors and explore how Datadog organizes all this data in APM.

Send Errors and Explore APM

Your Flask app is running and sending traces to Datadog. Every request is being recorded. But what happens when things go wrong?

In this step, you'll intentionally trigger errors and then use Datadog's Error Tracking and APM Service page to see exactly how Datadog captures, groups, and surfaces problems in your application.

In this step, get ready to:
  • Generate errors and view them in Error Tracking.
  • Explore the APM Service page metrics for your app.
  • Open a trace in the flame graph view.
Hit the error endpoint and explore Error Tracking

Your app has a /error endpoint that deliberately raises a ValueError. Hitting it multiple times gives Datadog enough error data to group into an issue.

  • Open a new Terminal window. Your Flask app is already running in the other terminal, so you need a separate one for sending requests.
  • Generate errors by running this command:
for i in $(seq 1 5); do curl http://127.0.0.1:5050/error; echo; done

What does this command do?

This loop sends 5 requests to your /error endpoint. Each request triggers the ValueError in your Flask app, which ddtrace automatically captures as an error span with the full stack trace.

  • You should see 5 JSON responses, each containing {"error":"Something went wrong! This is a simulated application error."}.
  • Switch to your Datadog browser tab.
  • In the left sidebar, hover over APM and click Error Tracking.
  • Wait 1-2 minutes for the errors to appear. Datadog needs a short time to process incoming error spans.

You should see an issue grouped under ValueError with your error message and a count of occurrences.

  • Click on the ValueError issue to open the issue panel.

The panel shows the full stack trace, first and last occurrence, total count, and a timeline of when the errors happened.

Why does Datadog group errors into issues?

In production, a single bug can produce thousands of individual error events. Error Tracking computes a fingerprint from the error type, message, and stack trace, then groups matching errors into a single issue.

This turns a noisy stream of events into a prioritized list of bugs to fix.

Don't see any errors in Error Tracking?

Make sure your Flask app is still running in the other terminal. If it crashed, restart it with the ddtrace-run command from the previous step.

Check that you're looking at the correct time range in the top-right corner of the Datadog UI. Set it to the last 15 minutes.

Help me troubleshoot why errors aren't appearing in Datadog

Explore the APM Service page

Datadog automatically generates performance metrics from your traces. The Service page gives you a single dashboard showing how your app is performing overall.

  • In the left sidebar, hover over APM and click Services.
  • Click on my-flask-app in the services list.

You should see graphs showing throughput (requests per second), error rate, and latency for your service.

  • Look at the Requests and Errors graph at the top. This shows total requests over time.
  • Scroll down to the Endpoints section. You should see your three endpoints listed: /, /error, and /work.

Where do these metrics come from?

You did not configure any of these dashboards manually. When ddtrace sends traces to the Datadog Agent, Datadog automatically computes throughput, error rate, and latency metrics from the trace data.

This is a core benefit of APM. You get full service observability with zero extra code.

Open a trace in the flame graph view

Individual traces show you the full lifecycle of a single request. The flame graph visualizes every span in that trace on a timeline so you can see exactly where time was spent.

  • In the left sidebar, hover over APM and click Traces.
  • Find a trace for the /error resource. You can filter by clicking Resource in the facets panel on the left and selecting GET /error.
  • Click on any trace row to open the Trace View.

The Flame Graph is the default visualization. You should see color-coded spans on a timeline representing the request lifecycle.

  • Notice the span is highlighted in red because it contains an error.
  • Click on the span to see the Span Info panel at the bottom. This shows the error message, stack trace, service name, and operation.

What is a flame graph?

A flame graph displays all spans from a trace on a timeline. Each horizontal bar represents a span. The length of the bar shows how long that span took.

Errors are marked with red highlights. In a more complex app with multiple services, the flame graph would show how a request flows through each service, making it easy to pinpoint where failures or slowdowns happen.

Don't see the error highlighted in red?

Make sure you selected a trace from the /error endpoint. Traces from / or /work are successful requests and won't show error highlighting.

Help me find the error trace in the flame graph

You now have full visibility into your app's errors and performance. Next up, you'll create a monitor that alerts you automatically when traffic spikes.

Create a Throughput Monitor

Your Flask app is sending traces and surfacing errors in Datadog. You can see throughput, error rate, and latency on the APM Service page.

But watching a dashboard only helps if someone is looking at it. In production, teams need automated alerts that fire when something goes wrong. In this step, you'll create a metric monitor that watches your app's request volume and alerts you when traffic spikes.

In this step, get ready to:
  • Create a new metric monitor in Datadog.
  • Configure alert and warning thresholds for request throughput.
  • Save the monitor and confirm it shows a healthy status.
Navigate to the monitor creation page

Datadog Monitors let you define conditions on any metric and get alerted when those conditions are met. You'll create a threshold alert on the trace.flask.request.hits metric, which tracks how many requests per second your Flask app receives.

  • In the Datadog sidebar, hover over Monitors to expand the menu.
  • Click New Monitor.
  • Select Metric as the monitor type.

What is a metric monitor?

A metric monitor compares a metric's value against a threshold you define. When the value crosses that threshold, Datadog fires an alert. The Threshold Alert detection method is selected automatically when you choose the Metric monitor type.

You should see the metric monitor configuration page with sections for defining the metric, setting conditions, and configuring notifications.

  • In the Define the metric section, type trace.flask.request.hits in the metric search field and select it from the dropdown.
  • In the from field, type service:my-flask-app to scope the monitor to your Flask service only.
  • Leave the metric aggregation set to the default avg by.
  • For the monitor query aggregation, confirm it is set to average.
  • For the evaluation window, confirm it is set to 5 minutes (the default).

Why average over 5 minutes?

The average aggregation calculates the mean value of the metric across the evaluation window and compares that single value against your threshold. A 5-minute window smooths out momentary spikes so you only get alerted on sustained high traffic, not brief bursts.

Don't see the metric in the dropdown?

The trace.flask.request.hits metric only appears after Datadog has ingested traces from your app. Make sure your Flask app is still running with ddtrace-run and that you've made at least a few requests to it.

Why can't I find my trace metric in the monitor dropdown?

Set alert and warning thresholds

Now you'll define when Datadog should consider traffic "too high" and fire an alert.

  • Scroll down to the Set alert conditions section.
  • Confirm the trigger condition is set to alert when the metric is above the threshold.
  • In the Alert threshold field, enter 10.
  • In the Warning threshold field, enter 5.

What do these thresholds mean?

When the average request rate over 5 minutes exceeds 10 requests per second, the monitor enters an Alert state (red). When it exceeds 5 but stays below 10, it enters a Warning state (yellow). Below 5, the monitor stays in an OK state (green).

  • Scroll down to the Configure notifications and automations section.
  • In the monitor name field at the top of this section, enter a descriptive name like High Request Throughput on my-flask-app.
  • In the message body, type a short explanation of what this alert means, for example: Request throughput for my-flask-app has exceeded the threshold. Investigate for unexpected traffic spikes or load issues.

Keep notification messages actionable

In real-world setups, you would route this notification to a Slack channel or PagerDuty. For this project, the default notification (email to your account) is fine. The key is that the message tells whoever receives it what is happening and what to check.

Save the monitor and verify its status
  • Click Create at the bottom of the page to save your monitor.
  • Datadog redirects you to the monitor's status page. Confirm the status shows OK in green.

Why is the status OK?

Your Flask app is currently receiving very little traffic (just the handful of test requests you've made manually). The average request rate is well below the warning threshold of 5, so the monitor reports a healthy OK status. In the next step, you'll flood the app with requests to trigger the alert.

  • To double check, click Monitors in the sidebar, then click Manage Monitors.
  • Confirm your new monitor appears in the list with a green OK badge.

Monitor shows No Data instead of OK?

This means Datadog hasn't received enough data points for the metric yet. Send a few more requests to your app by running a quick curl to http://127.0.0.1:5050/ and wait 1-2 minutes for the monitor to re-evaluate.

Why does my Datadog monitor show No Data?

Your throughput monitor is armed and ready. Right now everything is calm, but in the next step you'll simulate a traffic incident and watch this monitor fire in real time.

Simulate an Incident and Investigate

Your monitor is configured and watching for traffic spikes. Now it's time to put it to the test.

In this step, you'll simulate a real-world incident by flooding your app with hundreds of requests. You'll then use Datadog's monitoring tools to investigate the triggered alert and watch the full incident lifecycle from trigger to recovery.

In this step, get ready to:
  • Flood the /work endpoint with 500 concurrent requests.
  • Investigate the triggered alert in Datadog.
  • Observe the monitor recovering after traffic stops.
Flood the /work endpoint with requests

To trigger your throughput alert, you need to send enough requests to exceed the 10 requests-per-second threshold you configured. A bash loop that fires 500 requests in the background will generate exactly this kind of traffic spike.

  • Open a new Terminal window. Your Flask app should still be running in the other Terminal from earlier.
  • Flood the /work endpoint with 500 concurrent requests by running this command:
for i in $(seq 1 500); do curl -s http://127.0.0.1:5050/work & done

What does this command do?

  • for i in $(seq 1 500) creates a loop that runs 500 times.
  • curl -s http://127.0.0.1:5050/work sends a silent HTTP request to your Flask app's /work endpoint.
  • The & at the end runs each request in the background, so all 500 fire nearly simultaneously.

Your Terminal will flood with JSON responses as the requests complete. This is expected.

Why the wait?

Your monitor evaluates the average request rate over 5 minutes. It takes 2-3 minutes after the traffic starts for Datadog to accumulate enough data points to breach the threshold and transition to Alert status.

Not seeing any responses?

  • Make sure your Flask app is still running in the other Terminal window. Check for a line showing Running on http://0.0.0.0:5050.
  • If the app crashed, restart it with DD_SERVICE=my-flask-app DD_ENV=dev ddtrace-run python app.py and run the flood command again.

Having trouble getting the flood to work? Help me troubleshoot why my curl flood isn't reaching my Flask app.

Investigate the triggered alert

After 2-3 minutes, your monitor should transition from OK to Alert as the average request rate exceeds your threshold. This is your simulated incident.

  • Wait 2-3 minutes for the monitor to evaluate the traffic spike.
  • In Datadog, navigate to the left sidebar and click Monitors.
  • Click Triggered Monitors at the top of the Monitors page. This view only shows monitors with a triggered status (Alert, Warn, or No Data).
  • Find your throughput monitor in the list. It should show an Alert status.
  • Click on the monitor name to open the monitor status page.

What am I seeing on the monitor status page?

The status page shows graphs and events explaining why the monitor is in Alert. You'll see the Evaluated Data graph showing the 5-minute average crossing your threshold.

The Event timeline at the bottom logs each state transition with a timestamp. This is the start of your incident investigation record.

  • From the monitor status page, navigate to APM in the left sidebar, then click Services.
  • Click my-flask-app to open the APM Service page.
  • Look at the throughput graph at the top. You should see a clear spike corresponding to your flood of requests.

Why correlate the monitor with APM?

In a real incident, an alert tells you something is wrong. APM tells you what happened. By correlating the alert timestamp with the APM throughput graph, you can confirm the root cause was a traffic spike and see exactly when it started.

Stop traffic and observe recovery

The 500 requests from your bash loop have already completed. Now you'll watch the monitor recover as traffic drops back to zero.

  • Switch back to the Terminal where you ran the flood command. Confirm all the background processes have finished (your prompt should be back to normal).
  • Wait another 3-5 minutes for the monitor's 5-minute evaluation window to pass with low traffic.
  • Return to Monitors in the Datadog sidebar.
  • Click on your throughput monitor. The status should now show OK again.

What is the incident timeline?

On the monitor status page, the Event timeline shows the full lifecycle of your simulated incident. You'll see entries for when the monitor transitioned from OK to Alert (triggered) and from Alert back to OK (recovered).

This timeline is exactly what on-call engineers use to understand how long an incident lasted and when it resolved. Your complete cycle proves the monitoring pipeline works end-to-end.

✔️ My monitor recovered to OK

Excellent. You've just completed a full incident lifecycle: trigger, investigate, and recover.

ⓧ My monitor is still in Alert

  • Make sure you stopped sending traffic. If you ran the flood command multiple times, wait a full 5 minutes after the last run.
  • Check that your Flask app is still running. If it crashed, the monitor might not receive new data to evaluate.
  • Verify the evaluation window is 5 minutes. A longer window takes longer to recover.

Still stuck? Help me figure out why my Datadog monitor isn't recovering to OK status.

You've just completed a full incident investigation workflow. You triggered a real alert, correlated it with APM data, identified the root cause, and watched the system recover. This is the exact process teams use in production to handle outages.

Ready for a bonus challenge? The Secret Mission takes this further by adding custom spans to track slow database queries and building a latency-based monitor.

Secret mission

Add Custom Database Spans and a Latency Alert

Your throughput monitor catches traffic spikes, but what about slow individual requests? In production, a single slow database query can degrade the entire user experience without ever triggering a volume-based alert. In this secret mission, you'll add custom tracing spans that simulate a database query, then build a latency monitor that fires when response times cross a dangerous threshold.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses a Datadog 14-day free trial, so there are no ongoing costs during or after your trial.

Resources you used:

  • Datadog Agent installed on macOS (at /opt/datadog-agent).
  • Two Datadog metric monitors (throughput and latency).
  • Local Flask project directory with Python virtual environment.
  • Datadog free trial account.

Keep everything running

No action needed. Choose this if you're still actively exploring Datadog features during your free trial.

  • The Datadog Agent continues running in the background, using minimal CPU and memory.
  • Your monitors remain active and will keep evaluating metrics.
  • After 14 days, your trial reverts to the free tier (up to 5 hosts, 1-day metric retention). No billing occurs unless you explicitly upgrade.

Pause - I'll come back to this later

Stop the Datadog Agent to free up local resources without uninstalling anything.

  • Stop the Flask app by pressing Ctrl+C in the terminal where it is running.
  • Stop the Datadog Agent by running:
sudo launchctl kill SIGTERM system/com.datadoghq.agent
  • When you're ready to resume, restart the Agent by running:
sudo launchctl kickstart system/com.datadoghq.agent

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below.

  • Stop the Flask app by pressing Ctrl+C in its terminal.
  • Delete your Datadog monitors. In Datadog, click Monitors in the left sidebar, then click Manage Monitors. Hover over each monitor you created and click Delete to remove it.
  • Uninstall the Datadog Agent by running:
curl -L https://install.datadoghq.com/scripts/uninstall_mac_os.sh | bash
  • Delete your local project folder by running:
cd ~/Desktop
rm -rf [[PROJECT_DIR="your-project-folder-name"]]
  • To disable your Datadog organization account entirely, contact Datadog support through the in-app help menu.

That's a Wrap!

That's a Wrap!

Nice work! You just built a full observability pipeline from scratch, connecting a live Flask app to Datadog and proving you can monitor, alert on, and investigate production issues.

You've learned how to:

  • Build a Flask app instrumented with ddtrace for automatic tracing and error capture in Datadog APM.
  • Create a metric monitor that fires an alert when request throughput exceeds a threshold.
  • Simulate a traffic spike, trigger an alert, and investigate the incident end-to-end using Datadog's APM service page and monitors.
  • Added custom spans for database query tracking and created a latency-based monitor that alerts on slow responses.

Ready to quiz yourself?