With three monitors a list is enough. With thirty the searching begins: which ones belong to the customer who is calling right now? Which are just test systems? Who is actually responsible for the one that went down? Tags answer these questions without you having to make names ever longer.
How tags work in Uptime
- A monitor can carry up to 10 tags, each at most 30 characters long.
- Case does not matter: “Production” and “production” are merged into one tag.
- In the monitor form, the tag field suggests the tags your team already uses. That helps against typos and duplicates.
- On the dashboard you filter with the tag bar. “No tag” shows you what has not been put in order yet.
- The “List | Groups” switch groups your monitors: one collapsible card per tag.
Which axis do you sort by?
A few clearly separated axes have proven themselves. You do not have to use all of them, but every axis you do use should be set on every monitor.
- Environment: production, staging, development. The most important axis, because a failure in a test system is not worth an alert at midnight.
- Customer or project: when someone calls, you see at once whether something is on fire for them.
- Responsibility: the team or person who looks after it, such as backend, infrastructure or operations.
- Criticality: for example critical and normal. Use it sparingly, or soon everything is critical.
One tag or several?
One tag per axis is the normal case: a monitor has one environment, one customer, one responsibility. That a monitor carries several tags is intended, because that is how you later slice the list both ways. It gets difficult when a single tag expresses several things at once, such as “customer-a-production”. Then you need a new tag for every combination and can no longer filter by “production” alone. Keep the axes in separate tags.
How many tags are enough? Usually two to four per monitor. The limit of 10 is a ceiling, not a goal.
Naming: boring and consistent
- One spelling across the team: singular or plural, German or English, but not mixed.
- Short and without whitespace tricks, so they stay readable in the tag bar.
- The name says what something is, not how urgent you find it right now. “production” stays true, “important-this-week” does not.
- Take the suggestions in the form instead of typing anew. That prevents variants like “prod” and “production” side by side.
This matches what is also recommended for resources in cloud environments: a consistent tagging strategy by purpose, team and environment makes filtering easier and supports operations during an incident. The idea is the same, only smaller.
What this gives you during an incident
When several monitors are red at once, the grouped view helps: per tag you see whether everything in a group is affected. If all of one customer’s monitors go down, the cause is probably with that customer or a shared service. If only one monitor is affected, you look at exactly that one. This is a rule of thumb, not proof, but it tells you where to look first.
The tag filter also hides what does not matter right now. Filter on “production” and the failed test system does not distract you. Filter on the responsible team and it sees only its own monitors.
Checklist
- Every monitor has an environment.
- Every axis you use is set on all monitors. “No tag” on the dashboard should be empty.
- One tag per axis, never several things in one.
- One spelling; use the suggestions.
- Two to four tags per monitor are enough.
- New monitors get their tags when they are created, not “later”.
