Project Milestone Health Tracker

A worked example of an advanced workflow: a Claude-managed scheduled agent that, once a week, reads the Milestone tasks across a set of ClickUp projects and flags the ones that are overdue or closing in on their due date while still incomplete, publishing a digest to Slack. It is strictly read-only and never edits a milestone or any other task. There are no servers and no code to deploy: the agent is a saved prompt plus a schedule plus two MCP connectors, running in Claude’s cloud.

This workflow is ClickUp-only. ClickUp Milestones are a distinct task type in ClickUp’s product — a task whose Task Type is set to “Milestone” rather than the default type, shown with a diamond icon. Linear and Asana have their own milestone-adjacent concepts, but this guide (and its build-time tool discovery) is written and verified specifically against ClickUp’s MCP server. If your team runs project management elsewhere, this specific workflow does not have a confirmed equivalent yet.

What it builds

The finished workflow runs unattended on a weekly cron. Each run it pulls the Milestone-type tasks across a set of ClickUp Lists, Folders, or Spaces, checks each one’s due date against today and whether it’s already marked complete, and notifies your team with a digest of which milestones are overdue, which are due soon and still open, and which are on track — sorted so the ones that need attention are at the top.

Prerequisites

Before building, your Claude account needs all of the following:

Requirement	Notes
Conduit connector	Connected in claude.ai (https://conduit.wyre.ai/v1/mcp). Provides the ClickUp task-search tools. See Connecting an AI Client.
ClickUp connected in Conduit	The vendor connection is read-scoped today — the routine uses only read tools, no write scope is available or required.
Slack connector	The first-party Slack connector connected in claude.ai (https://mcp.slack.com/mcp). Provides slack_create_canvas and slack_send_message.
Scheduled routines access	Created via the /schedule capability; managed at claude.ai/code/routines.
A destination Slack channel	e.g. #pm-status. The Slack connector must have access to it.
At least one task in each covered project already set to Task Type “Milestone”	This workflow only finds tasks already marked as milestones in ClickUp — it doesn’t decide which tasks matter, your team does, by setting the type.
The Space, Folder, or List ID(s) for each project you want covered. ClickUp’s task-search tools query by that scope, not by a “project” object directly — see the build prompt.

Known gotchas

These are the things worth knowing before you build, based on what’s confirmed about ClickUp’s MCP server today rather than a live build.

• This guide does not hardcode the exact tool identifiers, unlike most other guides on this page — matching the same discipline the Project Time Visibility guide already uses for this same connector. ClickUp’s MCP server requires an authenticated connection even to list its own available tools, so the literal on-the-wire tool names haven’t been confirmed independently of a live connect. What is confirmed, from ClickUp’s own published MCP documentation: a tool that searches/retrieves tasks filtered by task type (Milestone is a task type value), and a separate tool that retrieves the full details of a single task by ID — useful if a routine needs more than the search result exposes for a given milestone. When you build this routine, ask Claude to list its available ClickUp tools first and use the one matching “search tasks by task type” or equivalent, scoped to Milestone; don’t assume a specific string.
• Milestone search filters by type, not directly by due date or status. ClickUp’s documented MCP filter capabilities are type-, tag-, and location-based rather than exposing due-date or status filters at the search level. That means the routine pulls every Milestone-type task in scope first, then compares each one’s own due-date and completion-status fields against today — the health check happens after the fetch, not as part of the query.
  • ClickUp’s connector is read-first — no write tools are available. The vendor connection’s OAuth scope is read only; write access to ClickUp (changing a milestone’s status or due date) is deliberately not requested. This workflow only reads task data, which matches that scope exactly — there’s nothing to accidentally overreach into.
• ClickUp enforces its own published rate limits, and they vary by plan and by whether the Everything AI add-on is active — not verified live for this guide. The Project Time Visibility guide confirmed a specific limit directly against live response headers; that check wasn’t repeated here, so no specific number is stated. A weekly sweep across a reasonable number of projects is unlikely to be the thing that hits a limit, but if you extend this routine to cover a large number of scopes individually, check your own account’s limit before assuming headroom.
• Faster-than-hourly cadences are rejected. The scheduler will not accept a cron more frequent than once an hour. A weekly cron is well within that limit.
• permitted_tools must be populated per connector. A routine with a connector attached but an empty permitted_tools list runs with no tools and silently does nothing — no error, no output. List the exact tool names the routine needs, confirmed from the live tool list at build time.
• A routine reaches only its attached connectors. The routine sandbox blocks arbitrary network egress, so notifications must go through the Slack connector’s tools, not an outbound webhook. Attach every connector the workflow touches.

The one-shot build prompt

With the connectors above in place, paste this to Claude. Because the exact ClickUp tool identifiers aren’t hardcoded here (see the gotcha above), the first step has Claude discover them from your live connection before building the routine.

Build me a scheduled Project Milestone Health Tracker agent. Do all of this
end to end:

1. Confirm the Conduit connector works and ClickUp is reachable. List the
   available ClickUp tools and identify: (a) the tool that searches/retrieves
   tasks filtered by task type (this is the one the routine needs — filter
   to Milestone), and (b) confirm no write-scoped ClickUp tools are present
   — the connection should be read-only. Record the exact tool name(s) you
   find; use those exact names in the routine, not a guessed name.
2. Ask me which Space, Folder, or List ID(s) to cover. Record them — they
   get baked into the routine prompt.
3. Confirm a Slack connector is connected. Note the destination channel name
   and ID. If Slack does not show in the /schedule connector list, read its
   connector_uuid and url from an existing routine that already uses Slack
   (RemoteTrigger list -> get -> mcp_connections).
4. Create a Claude-managed scheduled routine named "Project Milestone Health
   Tracker":
   - Schedule: weekly, cron "0 13 * * 1" (Monday 09:00 America/New_York =
     13:00 UTC). Faster-than-hourly cadences are rejected.
   - Attach TWO connectors, each with permitted_tools populated:
       * Conduit: the ClickUp task-search-by-type tool you confirmed in
         step 1 — READ only. Do not attach any ClickUp write tool.
       * Slack: slack_create_canvas, slack_send_message
     An empty permitted_tools list = the routine runs with no tools.
   - Routine prompt: every run, pull Milestone-type tasks for each
     configured scope, compare each one's due date against today and
     whether it's marked complete, bucket into overdue / due soon / on
     track, build a digest, publish it to Slack. Use the routine prompt
     below, substituting the exact tool name from step 1 and your own
     scope IDs.
5. Trigger a manual run and verify: a Slack message or canvas was posted,
   and the milestones reported for one project roughly match what you'd
   expect from a manual check in ClickUp.

The resulting routine prompt

This is the lean prompt the build process installs into the scheduled routine itself. Substitute the exact ClickUp tool name confirmed at build time, your own scope IDs, and destination channel.

You are the Project Milestone Health Tracker agent. You run weekly,
READ-ONLY against ClickUp. You must NEVER change a task's status, due date,
or any other field — only read.

Projects to check (scope ID - name):
- <scope-id-1> - <project name 1>
- <scope-id-2> - <project name 2>
- ... one line per project ...

1. For each scope above, call <exact ClickUp task-search-by-type tool name
   from build step 1> scoped to that Space, Folder, or List ID, filtered to
   Task Type "Milestone".
2. For each milestone returned, note its name, due date, and completion
   status. If the search result doesn't include everything you need, use
   the Get Task tool on that milestone's ID to fill in the gap.
3. Bucket each milestone:
   - Overdue: due date is in the past and it isn't marked complete.
   - Due soon: due date is within the next 7 days and it isn't marked
     complete.
   - On track: not yet due, or already marked complete.
4. Build a digest: project name, milestone name, due date, bucket. Sort
   Overdue first, then Due soon, then On track. Omit the On track section
   entirely if it would be the only thing in the digest that week — lead
   with what needs attention.
5. slack_send_message to the destination channel with the digest. If the
   digest is long, slack_create_canvas instead and post a one-line summary
   linking it.
6. If a scope returns no milestone-type tasks at all, or a call errors, list
   it in a "could not check" section instead of skipping it silently. Never
   guess a due date or status for a milestone that couldn't be read.

How it works

ClickUp only, stated plainly

Milestones are a ClickUp product feature — a task type, not a separate object — exposed through ClickUp’s own MCP server. This workflow doesn’t generalize across project-management tools the way some other advanced workflows generalize across RMMs or PSAs; it’s specific to teams running ClickUp and using the Milestone task type deliberately.

The routine only sees what your team already marked

This workflow has no opinion about which tasks are milestones — it reports on whatever’s already set to Task Type “Milestone” in ClickUp. If a team doesn’t use that type consistently, the digest will be thin or empty, which is an accurate reflection of the underlying data, not a bug in the routine.

A weekly cadence, by design

Milestone health is a slow-moving signal, similar to the time-tracking signal in the sibling Project Time Visibility guide — a milestone doesn’t go from on-track to overdue in the space of an hour. The routine runs every Monday morning so the digest is waiting before the week’s planning conversation happens.

Read-only by construction, matching the connector’s real scope

ClickUp’s vendor connection in Conduit grants read access only — write scope for editing milestones was deliberately not requested. The routine’s permitted_tools list can only ever contain read tools as a result, so there’s no path by which a run could change a milestone’s due date or status. The safety guarantee lives in the connector’s actual OAuth scope, not just the prompt.

Tool names are discovered at build time, not hardcoded here

Like the Project Time Visibility guide, this one doesn’t name the exact MCP tool identifier, because ClickUp’s MCP server requires authentication even to list its own tools, and no live connection was available to confirm the literal string. The build prompt above has Claude discover the real tool name from your own live connector before writing the routine, which is slower than copy-pasting a known-good name but doesn’t risk locking in a guess.

Extending it

Once the exact ClickUp tool identifiers are confirmed against a live connection, this same pattern combines naturally with the Project Time Visibility routine into a broader weekly project-health digest — hours logged and milestone status side by side, still strictly read-only.

Questions or a workflow you’d like documented? See Getting support.