Monitoring Your Django App Health on Fly.io

Fly.io is a neat choice for deploying Django fast and globally. What it doesn’t really give you out of the box, though, is a deeper picture of an application’s performance. Deployment is only part of the story. No matter which platform you’re using, operating a production application means you need to understand how it behaves.

AppSignal helps you fully grasp what happens on the Fly.io server. In this guide, you will install AppSignal’s instrumentation into a Django app, configure it correctly for Fly.io and see what you can expect when the data starts pouring in.

TL;DR Your Django app on Fly.io might be running, but without monitoring, you’re just flying blind. Errors are piling up, you’re wondering why queries are slow, and users are the first ones to tell you about downtime. Whoops! This guide will walk you through how you can connect AppSignal to your Django app on Fly.io so that you can track errors, performance, and host health from a single dashboard.

Prerequisites

Before heading into the monitoring stuff, make sure you have the following:

• Django app ready to deploy (or deployed) on Fly.io
• AppSignal account with an app set up
• flyctl installed and authenticated (Fly CLI docs)

Install Packages

Add the following to your requirements.txt:

appsignal
opentelemetry-instrumentation-django
opentelemetry-instrumentation-wsgi
opentelemetry-instrumentation-asgi

To instrument queries performed via the Django ORM, install the instrumentation for the SQL database that your application uses:

• MySQL
• PostgreSQL
• SQLite

Then install this locally:

pip install -r requirements.txt

Initialize AppSignal

After the packages are installed, run the install tool from your project's root directory:

python -m appsignal install

Enter the app name and the API key. To generate the key, navigate to your app in the AppSignal dashboard and copy it from App settings > Push & deploy.

This command will also create a __appsignal__.py file. Open that file and replace the contents with:

# __appsignal__.py
import os
 
from appsignal import Appsignal
 
appsignal = Appsignal(
    active=True,
    name="your-app-name",
    push_api_key=os.environ.get("APPSIGNAL_PUSH_API_KEY", ""),
)

Make sure to enter your proper app name. This has replaced the entered API key with an environment variable you will later set up in Fly.

Set up Django

In the settings.py file, update the ALLOWED_HOSTS variable to accept Fly's deployed host. Add the FLY_APP_NAME as well.

# hello_django/settings.py
import os
 
APP_NAME = os.environ.get("FLY_APP_NAME")
ALLOWED_HOSTS = [f"{APP_NAME}.fly.dev"]

Open up the manage.py file and add the following:

• appsignal module needs to be imported
• appsignal.start must be called in the main method to initialize the instrumentation

# manage.py
#!/usr/bin/env python
"""Django's command-line utility for administrative tasks."""
import os
import sys
 
# Add this import statement
import appsignal
 
def main():
    """Run administrative tasks."""
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', '<YOUR_APP_NAME_HERE>.settings')
 
    # Add this method call
    appsignal.start()
 
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)
 
if __name__ == '__main__':
    main()

💡 See here for more details regarding production setup (WSGI/ASGI) on AppSignal and Fly specifics.

Configure the Environment

After code is set up and instrumentation is ready, now is the time to configure the environment properly so that instrumentation can communicate back to AppSignal and Fly doesn’t complain.

Set Push API Key

⚠️ Your AppSignal's Push API key is sensitive. Please store it in Fly Secrets (not in fly.toml or, god forbid, source control).

Run the following command to set the Push API key in Fly Secrets.

🧠 Oh, and a quick reminder: you can find your push API key in AppSignal under App Settings > Push & deploy.

fly secrets set APPSIGNAL_PUSH_API_KEY="your-push-api-key"

Set Fly Configuration

In the fly.toml file, add the following:

app = "your-fly-app-name"
[env]
  APPSIGNAL_APP_ENV = "production"
  APP_REVISION = "$FLY_IMAGE_REF"

This helps AppSignal understand that it’s dealing with production data, thanks to APPSIGNAL_APP_ENV. Change it accordingly if necessary.

Launch and Deploy

To configure and launch the app, run the following command and its wizard:

fly launch

In the wizard, you can tweak the app name and deployment region. Plus, you can attach a database as you go. The wizard will create a Dockerfile, update the fly.toml with additional info, and use the environment settings you’ve put up earlier.

After the wizard is done, deploy the app:

fly deploy

Give it a couple of minutes, and then you can fire a few requests to your application.

What AppSignal Monitors on Fly.io

Once the app is calculating ones and zeros, here’s what you can get from the AppSignal instrumentation:

Error Tracking

Every unhandled exception is captured with a full stack trace, request context, and parameters. AppSignal groups duplicates automatically, so you see "this error has happened 47 times across 12 users" rather than 47 separate entries.

Request Performance

Incoming requests are traced with response timing, SQL queries, external HTTP calls, and time spent in each query. Slow requests surface in the Performance view broken down by endpoint.

Host Metrics

AppSignal measures CPU, memory, disk usage, and average load for your Fly machines. If a machine is running at 90% memory, you'll see it in AppSignal before Fly's health checks kill the process.

Logs

If you are sending application logs to AppSignal, they are searchable and directly linked to the traces they came from. So, when a request is slow, it shows up alongside the log lines it has generated. Context really is everything.

Uptime Monitoring

Configure an uptime monitor for your Fly app to get alerted when it goes down entirely. This one should be separate from Fly’s own health checks as a first line of defense.

On top of the usual stuff, AppSignal also has a few extra tools:

• Check-ins, with which you get alerted when processes fail, run off schedule, or exceed max duration
• Metric dashboards, which trace key metrics and create custom dashboards
• Anomaly detection, which notify you when metrics go over specified limits

After Deployment Checklist

Here are a few things you should keep an eye on after AppSignal starts monitoring your app:

• Slow queries, which can be found at Performance > Slow queries
• Memory trend, which you can access through Host Metrics > Memory
• Error rate after deployment
• Anomaly detection, after you have a baseline of data

Next Steps and Resources

A full AppSignal + Fly + Django setup takes under ten minutes. Most of it is just waiting for fly deploy to do its magic. Once AppSignal is on the watch, you get errors, performance data, query times, and host metrics for your Fly machines in a single place, without any additional infra to manage.

In case you wanna dig deeper, here are some extra resources:

• AppSignal Python docs (full configuration reference)
• Django instrumentation docs (instrumentation options)
• Fly.io Django docs (Fly-specific deployment details)

Not monitoring yet? Try AppSignal for 30 days and stay on top of mission-critical data. Missing production data is always more expensive than the tool that would have caught it.

Frequently Asked Questions (FAQ)

Does AppSignal work with Fly.io's multi-region deployments?

Yes. Each machine reports on its own to AppSignal.

Does AppSignal monitor Postgres or just the Django app?

AppSignal monitors the queries your Django app executes, not the Postgres machine directly.

Can I use AppSignal with Fly's auto-stop/auto-start machines?

Yes, but note that machines that are stopped and restarted will show gaps in host metrics. Error and performance data is only reported while the machine is actively handling requests, which is the expected behavior.

My app is in staging and production. Can I separate them?

In each environment's fly.toml, or by using fly secrets set, set APPSIGNAL_APP_ENV to "development", "staging" , or "production". AppSignal treats them as separate environments within the same app, so you can view each independently without noise from the other.