Tags: organize monitors and shape what public status pages show
Tags are plain text labels stored on each monitor and edited in the product UI. Teams use them to slice dashboards, while public status pages can list monitors manually and/or pull in anything sharing a tag configured on the status page—useful when clients should only see “payments” or “api” components instead of your entire catalog.
How tags are stored
Monitors keep a comma-separated tags field; normalise spelling up front because filtering compares the values you enter without trying to guess synonyms.
Filtering inside the app
Dashboard and list views can narrow down monitors by tag so operators focus on one client, geography, or tier without creating separate workspaces.
Public status pages and included tags
Status pages support manual monitor selection plus an optional included-tags list. When that list is set, monitors whose tags intersect the configured tokens appear alongside manual picks—exactly the behaviour described in the status page editor hints.
Compared to monitor names
Names describe a single URL; tags group many monitors under shared operational language such as “prod-eu” or “client-acme.”
Relation to alert contacts
Tags do not replace contacts—they help humans browse; incidents still route through the alert contacts attached to each monitor.
Agencies and multi-site setups
Agency workflows pair well with consistent tag vocabularies per client so public status pages stay readable when dozens of checks exist.
What SitePuls does not do
No hierarchical tag taxonomy, no automatic tag discovery from DNS, and no third-party CMDB sync—only the strings you maintain in SitePuls participate.
Next steps
Pick three recurring categories, add them to existing monitors, then configure a staging status page with included tags before publishing to customers.
What you can verify with SitePuls here
- Monitors keep a comma-separated tags string you edit in monitor forms—no separate taxonomy service.
- Public status pages can list manual monitor picks plus any monitor whose tags intersect the page’s included_tags list (case-normalized matching in the status page service).
- Dashboard and list screens let you filter monitors by tag to focus a large workspace on one client or subsystem.
- Tags organize visibility; alert routing still follows each monitor’s linked alert contacts.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
FAQ
Are tags case-sensitive?
Matching for status pages lowercases tokens when evaluating intersections—still keep a consistent convention to avoid duplicates like Prod vs prod.
How many tags per monitor?
The field is a single string with comma separation; stay concise so the UI remains readable.
Can guests see tags on public pages?
Public status templates render tag badges when monitors expose tags—only publish what you are comfortable customers reading.
Do tags affect billing?
Billing follows plan limits on monitor counts, not tag counts.
Can I import tags via API?
Automation depends on the APIs your deployment exposes—this page documents the product model, not every import script.
What if included_tags is empty?
Only manually selected monitors appear on the status page until you add tag filters.
Do tags change check intervals?
No—intervals remain per monitor; tags are organizational metadata.
Where do I edit tags?
Monitor create/edit forms and status page editors in the signed-in app.