How to Set Up Replit Monitoring Agent: Alerts, Auto-fix, Auto-republish and Email Settings

If you run a published app on Replit, you can now let an agent handle the first response to production problems: Monitoring Agent watches error logs, HTTP errors and latency, investigates when something trips an alert, attempts a validated fix and, only if you allow it, republishes that fix to your live app. Replit announced Monitoring Agent on October 22, 2026 as the next step after App Monitoring, which already sent uptime alerts. The practical question for builders is not “should I turn it on?” but “which of its three switches should I turn on, for which app?” This guide answers that, step by step.

Everything below comes from Replit’s own material: the launch post, the Monitoring Agent docs, the Monitoring docs, After you publish and Managing your spend. Replit’s UI changes often, so if a label differs slightly on your screen, the docs pages linked here are the source of truth.

What Monitoring Agent actually does

Replit’s launch post describes it as “an autonomous on-call engineer for their app.” Stripped of the marketing, the docs describe three separate settings that build on each other:

SettingWhat it allowsChanges your code?Changes your live app?
Monitoring alertsReplit checks your published app and records issues in a Monitoring alerts tableNoNo
Auto-fixAgent investigates each alert in the background and attempts a fixYes (proposes and validates a change)No
Auto-republishAgent publishes its validated fix automaticallyYesYes

The important line from the docs: “Auto-fix alone doesn’t authorize publishing changes to your live app.” Auto-republish is a separate opt-in, it is marked experimental, and it requires Auto-fix to be on.

When Auto-fix is on, each alert goes through the same loop, per the Monitoring Agent docs:

  1. Investigate the alert. Agent uses your app’s production metrics, runtime logs and code to find the cause.
  2. Attempt and validate a fix. If it finds an actionable cause, it makes a change and validates it. Replit is explicit that “an alert doesn’t guarantee a fix”: a problem in an external service, for example, may need action outside your app.
  3. Publish the fix. Only with Auto-republish on. Otherwise you review the result in Agent chat and republish yourself.

The launch post adds that Agent emails you a summary of what happened and what changed.

What triggers an alert

Automatic checks watch exactly three signals:

  • application error logs,
  • HTTP errors,
  • request latency.

That list is narrower than what Agent can look at when you ask it directly (more on that below). So a slow memory leak or a disk filling up will not necessarily fire an automatic alert, even though Agent can inspect those metrics on request.

Before you start

You need:

  • A published Replit app. Monitoring starts once the app is published; before that, the Monitoring tool just prompts you to publish.
  • A paid plan if you want uptime checks. Per the Monitoring docs, “Uptime checks require a paid plan and aren’t available for Scheduled Deployments.” Uptime checks are managed separately from monitoring alerts.
  • A budget you are comfortable with. The docs warn that Monitoring Agent runs “may incur Agent usage charges.” Every alert that Agent investigates is Agent work. Set a usage limit first (step 0 below).

Monitoring is configured per published app, so repeat these steps for each app you want covered.

Step 0: Put a ceiling on Agent spend

Because Auto-fix runs Agent in the background without you watching, set a usage limit before you turn it on. From Managing your spend:

  • Core accounts: go to Settings > Usage. In the Account usage section, select Manage limits and set a usage limit.
  • Organizations: open Usage and select Manage limits under Account usage. Organization budgets must be set in increments of $500, and you need organization admin or owner permissions.

Usage limits cap spending beyond your monthly credits; once you hit the limit, usage-based services are blocked until the next billing cycle or until you raise it. The same dialog has a service shutdown limit, which suspends services when reached. Think carefully before setting that one on a production app: it is a hard stop for your services, not just for Agent.

You can watch where credits go on the Usage page, filtered by project, which makes it easy to see what Monitoring Agent runs on a single app cost.

Step 1: Open the publish settings

Open the Publishing tool in your project.

  • Existing published app: open its publish settings.
  • New app: you configure monitoring during your first publish, in the publish pane.

Step 2: Turn on monitoring alerts

  • Existing published app: switch on Monitoring alerts. The docs say “the change saves immediately without republishing.”
  • First publish: switch on Enable Active monitoring under Suggested add-ons. This also enables uptime checks where available.

At this point you have alerting only. Nothing will touch your code. If you want to see how noisy alerts are on your app before handing anything to Agent, this is a good place to stop for a few days.

Step 3: Turn on Auto-fix

Switch on Auto-fix in the same settings to let Monitoring Agent investigate and fix monitoring errors.

  • Existing app: saves immediately.
  • New app: select Publish to apply your settings and start monitoring.

With Auto-fix on and Auto-republish off, Agent does the investigation and prepares a validated change, and you decide what goes live. The After you publish page covers the manual path: select Publish again and your app updates at the same URL.

Step 4: Decide on Auto-republish

Switch on Auto-republish only if you want Agent to push its fixes live without review.

  • Existing app: saves immediately.
  • New app: takes effect from your first publish.

Replit’s own warning is worth repeating verbatim: “Some changes, including migrations and index operations, may be risky.” A sensible split:

Your appSuggested setup
Prototype, internal tool, low-traffic side projectAlerts + Auto-fix + Auto-republish is reasonable; the cost of a bad fix is low and the cost of being down overnight is annoying
App with paying users or real dataAlerts + Auto-fix, Auto-republish off; review each fix in Agent chat, then republish yourself
App with a production database you care aboutSame as above, and read every fix that touches schema, migrations or indexes before publishing
You just want to know when it breaksAlerts only

To back out later, the docs give two levers: turn off Auto-fix to stop automatic investigations and fixes (you can leave Monitoring alerts on to keep getting alerts), or keep Auto-fix and turn off Auto-republish to review changes before they go live.

Step 5: Set your alert emails

Alert emails are controlled in your personal settings, not the app:

  1. Open Settings > Notifications.
  2. Find Active monitoring alerts.
  3. If the severity selector is disabled, enable production alert emails first.
  4. Pick one of: Critical severity only, High severity and above, Medium severity and above, All severity levels, or No emails.

For teams, there is a separate account-wide setting. In the account’s advanced settings, open Monitoring alert recipients; authorized admins can choose Off, Admins or Custom recipients, with their own severity threshold.

One detail that trips people up: “Turning off emails doesn’t turn off monitoring or Auto-fix.” If you mute emails but leave Auto-fix on, Agent keeps working (and spending) in the background. Check the alerts table and your usage page instead.

Step 6: Review alerts in the Monitoring tool

Open Monitoring under Replit Cloud in the Tools pane and find the Monitoring alerts table:

  • Active: issues that currently affect your app.
  • Resolved: issues that stopped affecting your app within the last 30 days.

Expand an alert to see why it fired and how many monitoring passes detected it. The same tool shows uptime, requests and unique IPs, HTTP statuses, request duration buckets, CPU and memory utilization, and logs. Replit keeps deployment logs for 30 days, filterable by Errors only, a search phrase, or a date range.

Step 7: Ask Agent about production directly

You do not need an alert, or Auto-fix, to use Agent on production data. The docs suggest prompts like these in Agent chat:

  • “Why did my app return 500 errors in the last hour?”
  • “Which endpoints were slowest today? Compare their p50 and p99 latency.”
  • “Check CPU and memory usage since my last publish.”
  • “Read the runtime logs for the revision that failed to start.”

Replit’s advice: include the approximate time, your time zone and the affected endpoint when you know them, so Agent can narrow the search. The Monitoring docs add a simple trick: paste the timeframe of an error spike from the HTTP Statuses chart into Agent chat and ask it to check the logs.

What Agent can see on request

Agent can query more telemetry on demand than the three alert signals. Available metrics depend on your deployment type and cloud provider:

  • HTTP traffic: request count, request latency, 4xx and 5xx counts, availability.
  • Endpoint performance: per-endpoint request count, latency (average, p50, p95, p99), and 4xx/5xx counts.
  • Compute: CPU and memory utilization, active instance count, startup latency, instance uptime.
  • Storage and network: disk usage, disk utilization, network egress.
  • Application errors: error log count and runtime logs filtered by severity or deployment revision.

This is useful even if you never enable Auto-fix: it turns “my app feels slow” into a concrete question with numbers.

Troubleshooting

An alert shows “Cannot measure.” Per the docs, that label means Replit cannot currently evaluate that alert. It is not the same as healthy. Check the relevant chart and logs yourself, or ask Agent about that signal.

Uptime checks are missing. Uptime checks need a paid plan and are not available for Scheduled Deployments. They are also managed separately from monitoring alerts, so turning on Monitoring alerts on an existing app does not by itself enable them.

Auto-fix ran but nothing changed in my live app. Expected if Auto-republish is off. Review the result in Agent chat and select Publish to make it live.

Agent investigated but did not produce a fix. Replit says alerts don’t guarantee a fix, and gives an external service outage as an example. Check whether the root cause is outside your code: a third-party API, a quota, an expired credential.

I’m not getting emails. Check Settings > Notifications > Active monitoring alerts. If the severity selector is greyed out, production alert emails are disabled; enable them first. On team accounts, also check Monitoring alert recipients in the account’s advanced settings.

My performance problem never triggers an alert. Automatic checks only cover error logs, HTTP errors and latency. CPU, memory, disk and egress issues need you to ask Agent, or watch the infrastructure charts.

Costs went up after enabling it. Each background investigation is Agent work billed under Agent billing. Filter the Usage page by project, set a usage limit, or switch Auto-fix off and keep alerts on.

FAQ

Is Monitoring Agent the same as App Monitoring? No. App Monitoring, launched earlier in 2026, gives uptime checks and emails when your app goes down. Monitoring Agent builds on it: the launch post says “your agent doesn’t just tell you what broke, it makes the fix as well.”

Can I get alerts without letting Agent edit my code? Yes. Monitoring alerts, Auto-fix and Auto-republish are separate. Turn on alerts only.

Can Agent deploy without my approval? Only if you enable Auto-republish, which is experimental and requires Auto-fix.

Do I have to republish to change these settings on an existing app? No. On an existing published app, the monitoring alerts, Auto-fix and Auto-republish toggles save immediately.

How long are logs and resolved alerts kept? Deployment logs are retained for 30 days. The Resolved tab lists issues that stopped affecting your app within the last 30 days.

Is this a replacement for a real on-call rotation? Replit pitches it as one for solo creators and small teams. For anything with real users and data, the safer reading of the docs is: let Agent do the investigation and draft the fix, and keep a human on the publish button.