One web UI per server
Each server shows only its own runs. Checking last night's failures on five servers means opening five web UIs.
Dagu Cloud
The control plane for your Dagu servers
Connect every self-hosted Dagu server to Dagu Cloud. See their health and runs in one console, alert your team where it works, retry, stop, and approve runs without signing in to each server, and let ChatGPT or Claude operate them through one MCP endpoint. Workflows keep running only on your servers, which connect out; nothing opens inbound.
Free for one server. Team and Pro cover every licensed server and add acting on runs, MCP, and your team. Monitoring needs Dagu v2.19.1 or later (v2.19.2 on the free plan); acting on runs and MCP need v2.22 or later.
Your servers
- prod-eu-1dagu 2.19.0
- prod-us-2dagu 2.19.0
- batch-01dagu 2.19.0
Workflows run here
HTTPS, outbound only, every 60 seconds
console.dagu.shNever runs workflows
OverviewServersRunsAlertsNotifications
Alerts by email, chat, PagerDuty, or webhook when something breaks, and again when it recovers
Many servers, nowhere to run them from
Each Dagu server is complete on its own, with its own scheduler, run history, and web UI. With several servers, that also means several places to check, and several places to sign in to when a run needs a hand.
No list of every failure
Nothing collects the failures of all servers in one place, so nobody sees the whole picture.
Problems surface late
A stopped scheduler or a server that went quiet raises no error. Scheduled workflows just stop running until someone notices.
Alerting set up server by server
Failure emails need mail and notification settings on every server, kept in step by hand.
Every fix means another sign-in
Retrying a failed run or approving a waiting step means finding the right server, opening its web UI, and signing in there.
No safe way in for AI
Letting ChatGPT or Claude work on a server behind a firewall means opening a port or handing out an API key.
One console for every server
The Monitoring section of Dagu Console has an Overview, Servers, Runs, Alerts, Notifications, and Insights page, plus a page for each server, workflow, and alert. Every member of the workspace can view them.
Overview: what needs attention now
Servers reporting, failures today (UTC), runs in progress, and the success rate over the last 7 UTC days. Needs attention lists what waits for a person, open alerts, and today's failures, each with its action in the row.
- Not reporting
- Not checking in
- Offline
- Scheduler stopped
- Failing workflows
- Events lost
- Monitoring off
Servers: every server and its status
Each connected server with its status, Dagu version, last report, failures today (UTC), success rate over 7 UTC days, and open alerts. On Team and Pro, also each server's CPU, memory, and disk use.
- Reporting
- A report arrived in the last 5 minutes.
- Not reporting
- The server reported before, but not in the last 5 minutes.
- Not checking in
- No license check-in for more than 26 hours.
- Offline
- No license check-in for more than 72 hours.
- Monitoring off
- Monitoring was turned off on the server, or Dagu Console holds no report from it.
- Scheduler stopped
- The last report counts no running scheduler, so scheduled workflows do not start.
- Events lost
- The server was cut off longer than its event store keeps events, so some finished runs could not be sent.
Each server: health and recent history
A page per server. Overview shows its health (Dagu version, OS and architecture, process start, last report, last check-in), the services from the last report, open alerts, and its latest failures. Runs lists its runs. Workflows shows each workflow's finished runs per UTC day over 14 days, with runs, failures, success rate, and average and longest duration. On Team and Pro, Overview also charts the machine's CPU, memory, and disk use over the last 24 hours.
Runs across all servers
Runs in progress come first, then finished runs, newest first. Each run has a permalink to its attempts.
Filter by server, workflow, status (failed, succeeded, running, waiting, or queued), and range: the last hour, 24 hours, 7 days, 14 days, or, on Team and Pro, 30 days.
Insights: trends over 7, 30, or 90 days
Runs, failures, and success rate against the previous period, runs per day, and every workflow with its p95 duration and how it changed. Today's runs count as they finish.
Each workflow: is it failing, or getting slower?
A page per workflow with its open alert, runs per day, success rate, and p50 and p95 duration over 7, 30, or 90 days, plus its recent runs and the steps it failed at. Owners can mute it here.
Act from the console, or from your AI
Dagu Cloud reaches each server over a connection the server opens, so members and MCP clients can act on runs without an inbound port, VPN, or API key.
Act on runs in the console
Read a failed step's log, retry or stop a run, and approve or reject a step that waits for a person, right from the Overview, the run, or its alert.
One MCP endpoint for every server
Connect ChatGPT, Claude, or another MCP client once. It reads runs and logs, starts and retries workflows, and edits DAGs across the workspace's servers, as each member's role allows.
Bounded by each server
Each server's administrator turns remote access on and sets the highest role it allows. Every call is signed for that request alone and recorded in the server's own audit log. Dagu Cloud keeps no log of calls.
On Team and Pro, or in a trial. Requires Dagu v2.22 or later.
How remote access worksOne alert per problem, not one email per failed run
An alert belongs to one workflow or one server. It opens once, counts what follows, and resolves by itself when the problem ends.
A workflow fails
A failed run opens the workflow's alert. Later failures add to its count without another message, and the next successful run resolves it.
A server stops reporting
No report for 10 minutes, or 25 on free monitoring, opens the server's alert, so a dead host or a stopped process gets noticed. Its next report resolves it.
A disk fills up
Team and ProWhen the disk that holds a server's data directory is 90% full, an alert opens before runs, logs, and queues stop. It resolves once the disk is below 85%.
Memory or CPU stays high
Team and ProMemory over 90% for 10 minutes opens an alert, and CPU too once turned on. The percent and minutes are set for the workspace or for one server.
A run runs far too long
Team and ProA run still going after twice its workflow's usual time, and at least 10 minutes more, opens an alert before anyone wonders why a report is late. It resolves when the run ends.
A queue stalls
Team and ProA queue whose next run waits 10 minutes while it has room, or while no worker takes it, opens an alert. A queue that is simply full waits its turn.
- Each alert has a page with what failed, on which server, and a timeline of when it opened, every email and post, and who acknowledged it.
- Anyone in the workspace acknowledges an alert from its page, and a recipient straight from the email, without signing in. A PagerDuty incident is acknowledged with it.
- On Team and Pro, alerts no one acknowledged are posted again every hour, 4 hours, or day, up to 6 times. Snooze them for an hour, a day, or until 9:00 in your time zone.
- Alerts that open or resolve together arrive in one email. A channel gets at most 20 posts at once, and a summary of the rest.
- Aborted and rejected runs count as failures in totals, but neither open nor resolve an alert.
- Times in emails and posts follow your workspace's time zone. A noisy workflow can be muted: its alerts are still recorded, but nobody is notified.
Workflow alerts need the Health and run status level. Emails come from no-reply@dagu.sh.
Alerts where your team already looks
Alert emails go to owners and admins, and to the members and verified outside addresses you add, each with one-click unsubscribe. On Team and Pro, alerts also go to up to 10 destinations: Slack, Microsoft Teams, Google Chat, Discord, PagerDuty, and signed webhooks.
- Slack
- Microsoft Teams
- Google Chat
- Discord
- PagerDuty
- Webhook
Adding a destination sends a test, and each one keeps a log of every post and its answer. A failed post is retried with backoff for up to a day, and a destination that refuses alerts three times in a row stops and says so.
A weekly summary for owners
Team and ProEvery Monday at 8:00 in the workspace's time zone, each owner gets an email that sums up the week before. One link stops it.
- Finished runs and the success rate, against the week before
- Alerts opened and resolved, and how fast they were acknowledged and fixed
- The workflows that failed most, and those that got slower
- Servers that went quiet, and destinations that stopped taking alerts
Execution and data stay on your servers
Your servers send reports to Dagu Console. Dagu Console never connects to them and never runs workflows.
Outbound HTTPS only
Reports are HTTPS requests from the server to console.dagu.sh. No inbound port is opened, and nothing connects into the server.
Workflows never wait on it
If Dagu Console cannot be reached, workflows run as usual. The server retries and sends the runs it missed once the console is back.
Off until you turn it on
Monitoring is off by default and chosen per server by its administrator. Connecting or upgrading a server sends nothing beyond its license check-in.
Three levels
Health only sends what the server runs. Health and run status adds the status of its runs, and is needed for workflow alerts. A third level also sends failed steps' error messages, so alerts show why a run failed.
What leaves your server
Dagu version, OS and architecture, and when the server process started
- Health only
- Sent
- Health and run status
- Sent
Number of running schedulers and registered coordinators
- Health only
- Sent
- Health and run status
- Sent
On a paid plan or trial: CPU, memory, load averages, and the data directory's disk use
- Health only
- Sent
- Health and run status
- Sent
Each finished top-level run: DAG name, run ID, attempt ID, status, trigger, and when it was queued, started, and finished
- Health only
- Not sent
- Health and run status
- Sent
Names of a run's failed steps, up to 50
- Health only
- Not sent
- Health and run status
- Sent
Runs queued, running, or waiting, up to 200 per report
- Health only
- Not sent
- Health and run status
- Sent
Logs, outputs, parameters, environment, step commands, DAG YAML, and secret values
- Health only
- Never sent
- Health and run status
- Never sent
Every report also carries the server's license ID, server ID, and heartbeat secret, as its license check-in does. DAG and step names are sent only with run status; choose Health only if you consider them sensitive. Failed steps' error messages are sent only at a third level, Health, run status, and error messages: the end of each error, with declared secrets masked.
Set up in three steps
Requires Dagu v2.19.1 or later (v2.19.2 or later for free monitoring), and the server must reach https://console.dagu.sh over HTTPS.
- 01
Connect the server to Dagu Console
In Dagu, open Plan & features and select Connect to Dagu Console, run dagu license activate, or start the server with a server key. Servers with offline licenses do not report.
- 02
Choose what to report
Select Turn on in the Monitoring section of Plan & features, then choose Health and run status or Health only. The choice applies at once, without a restart.
For servers managed as code, set the level in the configuration file, or set DAGU_CLOUD_REPORT=runs:
cloud: report: runs # off, health, or runs - 03
See it in Dagu Console
The server reports every 60 seconds, and within about 5 seconds when a run fails or the runs in progress change. It appears under Monitoring in Dagu Console.
Plans, retention, and limits
What each plan covers, how long Dagu Cloud keeps what servers report, and how much it stores a day.
Plans
Free for one server per workspace, with lower limits: a report every 5 minutes, 100 stored runs a day, 7 days of run history, and email alerts to owners and admins. Team and Pro cover every licensed server, with 30 days of run history, chat, PagerDuty, and webhook destinations, reminders, running-too-long alerts, and the weekly summary.
Compare plansRetention
- Finished runs
- 30 days
- Daily totals per workflow
- 13 months
- Resolved alerts
- 90 days after they resolve
- Open alerts
- Until they resolve
Free monitoring shows the last 7 days of finished runs, and a trial the last 14. A server that sends no report for 30 days is removed from monitoring, with its daily totals and alerts.
Daily run limit
Each workspace stores up to 500 finished runs per UTC day, or 100 on free monitoring. Runs past the limit still count toward the daily totals and still open and resolve alerts, but they are not added to the run list. Storing resumes at 00:00 UTC.
Need more? Contact usRun every Dagu server from one place
Read the setup guide, or open Dagu Console and connect your first server. Free for one server; start a trial for Team or Pro.