What should I name an uptime monitor?

Name it so that the alert alone tells the reader what broke and how badly, without opening the dashboard. A format that works is environment, service, and what the check asserts, separated consistently: prod · api · /health 200, prod · api · /v1/orders contains "items", staging · web · homepage. Put the most important word first so the list sorts into groups, keep the URL out of the name because the URL is stored separately and shown in alerts anyway, and add bracketed tags like [p1] or [billing] when a relay or a human needs to route on them.

Does CronAlert support tags or folders for monitors?

Not as a separate feature. The monitor list offers search across names and URLs, a status filter for up, down, unknown, and paused, and sorting by name, status, URL, interval, or last check. Teams are the hard grouping boundary: each team has its own monitors, alert channels, status pages, and API keys. Within a team, a consistent name prefix does the job of a folder, because the search box matches substrings of the name, so searching prod · api shows exactly that group.

When should I use separate teams instead of name prefixes?

When the groups need different alert destinations or different people. Alert channels in CronAlert are team-wide: every monitor on a team notifies every enabled channel on that team. If the billing service should page the payments on-call and the marketing site should post to a different Slack channel, those belong on two teams. Agencies use one team per client for the same reason, plus a per-client status page and API key. If everyone gets the same alerts, prefixes are enough and one team is simpler.

Should I pause or delete monitors I no longer need?

Pause for anything that might come back within a quarter: a staging environment that is being rebuilt, a seasonal landing page, a service under a planned migration. Paused monitors stop checking and alerting, keep their history, still count toward the plan limit, and show up under the paused filter so they are easy to review. Delete monitors for things that are gone for good, such as a former client's sites or a decommissioned service, and do it the same week they go away, because every stale monitor is either a false alarm waiting to happen or a slot you are paying for.

How do I rename a lot of monitors at once?

Through the API or the MCP server. The REST API lists monitors and updates each by ID, so a short script can apply a naming convention to a whole team in one pass; the MCP server gives an AI assistant the same list and update tools, so you can describe the convention in a sentence and have it applied. Both are available on every plan for reading; writing needs the Pro plan's full API. Export the list first, review the proposed names, then apply, since monitor names appear in alert history and on status pages.

How to Organize 100 Uptime Monitors: Naming Conventions, Tags in Names, Teams, and Status Page Groups

Ten monitors organize themselves. At a hundred, the list is a liability: there are three things called API, the alert that just fired says website and you do not know which one, a status page shows a monitor for a feature you removed in March, and a former client's sites are still paging the on-call phone. None of that is a monitoring failure; it is a naming failure, and it compounds every time someone adds a monitor in a hurry. This guide is the set of conventions we see working on large fleets, written against what CronAlert actually gives you to work with.

Those tools are: a monitor list that searches by name or URL, filters by status (up, down, unknown, paused), and sorts by name, status, URL, check interval, or last check; teams, each with its own monitors, alert channels, status pages, and API keys; status pages that show a chosen subset of a team's monitors; pause and maintenance windows; and an API and MCP server for bulk changes. There are no tags or folders as separate features, which is why the name carries more weight than you might expect.

The job of a monitor name

A monitor name is read in three places, and a good one works in all of them:

In an alert, on a phone, at 3 a.m. The reader needs to know what broke and how much it matters before opening anything. "api" fails this test; "prod · checkout-api · /health" passes.
In the list, sorted by name. Names that share a prefix sort into groups, so the prefix is your folder.
In a search. The search box matches substrings of the name and the URL, so a consistent token like prod or client-acme turns the search into a filter.

It is also read by machines if you use a webhook relay: the Opsgenie, incident.io, and Google Chat relay examples all parse bracketed tags out of the monitor name to set priority or pick a destination. That makes the name the one field you fully control that also travels with every alert.

A name format that sorts, searches, and routes

The format that has held up best is three parts, most general first, with one consistent separator:

<environment> · <service> · <what the check asserts>   [tags]

prod · checkout-api · /health 200
prod · checkout-api · /v1/orders contains "items"       [p1]
prod · www · homepage contains footer
prod · www · sitemap.xml 200
staging · checkout-api · /health 200
jobs · nightly-report · heartbeat 24h                   [p2] [data]
client-acme · www · homepage                            [acme]

Environment or owner first. prod, staging, jobs, or a client slug. This is what you filter by most, and it is what you want grouped when the list is sorted by name. Keep the vocabulary short and fixed; "production", "prod", and "PROD" are three groups.
Service second. The deployable unit or site, in the form your team already uses in repositories and dashboards, so the alert name matches the thing someone will go look at.
The assertion third. Not the URL (the URL is stored on the monitor and shown in every alert anyway) but what a green check proves: /health 200, contains "items", expects 403 for an inverse monitor, heartbeat 24h. This is the part people skip and the part that saves the most time later, because a monitor is only as good as what it asserts, and writing the assertion into the name makes a weak monitor visible in the list.
Tags last, in brackets. Priority ([p1] to [p4]), a routing key ([billing], [acme]), or a flag ([flaky] for a monitor you are tuning). Brackets are easy to parse with a regex and easy to ignore by eye.

Pick one separator and keep it. The middle dot above is pleasant but any character works; the mistake is mixing -, /, and | across monitors created by different people. Write the convention down in the team's runbook in two lines, with two examples, and link it from wherever new monitors get requested.

Teams: the boundary that actually separates things

Prefixes group monitors visually. Teams separate them operationally. In CronAlert, every monitor, alert channel, status page, and API key belongs to a team, and alert channels are team-wide: every monitor on a team notifies every enabled channel on that team. So the question that decides whether two groups of monitors belong on one team or two is: should they alert the same people through the same channels?

Situation	Prefix	Separate team
Prod and staging, same on-call	✓ `prod ·` / `staging ·`
Billing pages payments on-call, marketing site posts to #web		✓ one team each
Agency with several clients		✓ one team per client (own status page, own API key)
Side projects alongside work monitors		✓ keep personal on the personal team
Background jobs vs HTTP checks, same people	✓ `jobs ·`

Team members on Team and Business plans see the teams they belong to and switch between them; alert routing with teams goes through the design in detail, including the relay alternative when you want one team but several destinations. The agency guide covers the per-client version.

Status pages: a selection, not a folder

A status page shows the monitors you select for it, from the team it belongs to. It is not a grouping mechanism for the fleet; it is a public view onto part of it. Two conventions keep status pages honest:

Only customer-facing monitors go on a public page. prod · www · homepage yes; prod · checkout-api · /v1/orders contains "items" probably yes; jobs · nightly-report and anything staging no. The assertion part of the name makes this decision fast.
Monitor names are visible on the page. If the public name should differ from the internal one, that is a sign the internal name has leaked implementation detail (an internal hostname, a ticket number) that belongs in the URL or the tags, not the service part of the name.

Free includes one status page, Pro three, Team and Business unlimited, so on Pro the natural split is one page per product or per client rather than per environment. Status page best practices covers what to show and what to leave off.

Pause, maintenance, or delete

Pause a monitor for anything that will come back within a quarter. Paused monitors stop checking and alerting, keep their history, still count toward the plan limit, and are one click away under the paused filter, which doubles as a to-do list of things to resume or remove.
Maintenance windows (Pro) are for planned work on a live service: checks continue but alerts are suppressed for the window, so the history shows what happened without paging anyone. Use them instead of pausing when you want the record.
Delete when the thing is gone: a decommissioned service, a client who left. Do it the same week, and if the team was per-client, delete its monitors, channels, and status pages before deleting the team itself, because deleting a team moves whatever it still owns to the owner's personal team rather than removing it. Stale monitors are the single largest source of ignored alerts, and ignored alerts are how real ones get missed; alert fatigue starts with the list.

Bulk renames with the API or MCP

Applying a convention to an existing fleet by hand is how conventions die. The REST API lists a team's monitors and updates each by ID, so a short script renames everything in one pass with a PUT per monitor; on Free the API is read-only, so the write half needs Pro. Export first, generate the proposed names, review them in a spreadsheet (this is where you notice the two monitors that are actually the same check), then apply:

# list → propose → apply; review proposed.csv before the second step
curl -fsS -H "Authorization: Bearer $CRONALERT_API_KEY" https://cronalert.com/api/v1/monitors \
  | jq -r '.data[] | [.id, .name, .url] | @csv' > current.csv
# ... edit into proposed.csv with id,new_name ...
while IFS=, read -r id name; do
  curl -fsS -X PUT -H "Authorization: Bearer $CRONALERT_API_KEY" -H "Content-Type: application/json" \
    -d "{\"name\": $name}" "https://cronalert.com/api/v1/monitors/$id"
done < proposed.csv

With the MCP server connected to Claude Code or Cursor, the same job is a sentence: "rename every monitor on this team to <env> · <service> · <assertion>, inferring env from the hostname, and show me the list before applying." Hand the assistant a read-only key for the review step and a read-write key only for the apply step; the MCP guide explains key scopes and the confirmation step on deletes. The import endpoint is the other bulk tool: when a new client or service arrives, generate its monitors from a list with the names already in convention rather than typing them.

The quarterly audit

Fifteen minutes, once a quarter, in this order:

Sort by status. Anything down for more than a day is either a real problem nobody owns or a monitor for something that no longer exists. Fix or delete.
Filter paused. Resume what came back; delete what did not.
Sort by last check, oldest first. Monitors that have not checked recently are paused, locked by a plan change, or on a team nobody looks at.
Search each environment prefix and count. If staging has more monitors than prod, something is upside down.
Read the assertion part of every prod name. Any monitor whose assertion is just "200" on a page that could return a 200 error page is a candidate for a keyword; the list tells you which ones without opening them.
Check every status page still shows only customer-facing monitors with presentable names.

How many monitors you need is the sizing companion to this audit: the goal is one monitor per failure domain, named so that the list reads as a map of the system.

Frequently asked questions

Should the URL be in the name?

No. The URL is stored on the monitor and included in every alert and API response. Putting it in the name makes the list unreadable and goes stale when the path changes. Put the assertion in the name instead; /health 200 is a path and a promise, not a URL.

How long can a name be?

Up to 200 characters, which is far more than the format above needs. Aim for under 60 so it fits in a push notification and a status page row; if a name needs more, the service part is probably two services.

What about heartbeat and TCP monitors?

Same format. The assertion part states the expectation: heartbeat 1h, heartbeat 24h, tcp 5432. For heartbeats, the service part names the job, and a jobs · prefix groups them. Monitor types explained covers the three types.

Can two monitors have the same name?

Technically yes, which is exactly the problem. The audit's sort-by-name step surfaces duplicates immediately; one of them usually has a weaker assertion and should go.

Get started

Write the two-line convention, rename the ten monitors that alert most often, and move anything with a different audience to its own team. The rest can follow in the quarterly audit. Create a free CronAlert account and start the fleet in convention from the first monitor. Related reading: setting up uptime monitoring, how many monitors you need, routing alerts with teams, team monitoring, and what a monitor should assert.