Service Tags

According to the API:{entity_type}~1{id}~1change_tags/post

only “users”, “teams”, “escalation_policies” can have tags set on them.

Can we also have to ability to tag services?


Hey Neil,

Thanks for reaching out! We do not currently offer this functionality, but I have relayed this feature request to our Product team. If you can let me know a bit more about your use case and how this feature would help you, I’m happy to pass along your feedback to our product team!

All the best,

I am working on a project that will automate on-call pay submissions to WorkDay. Not all PagerDuty services are eligible for this on-call pay. So I would like to be able to determine using a tag if a service is eligible.


Thanks for the feedback, Neil! We’ve taken note of your use case as we relay this to our Product team. Feel free to reach out to us in if you have any questions or need assistance with anything else!

1 Like


I voted on this feature request.
Note it has also be requested for incidents:

IMHO it will be great to add tags on many PagerDuty resources like services, business services, teams and schedules.


This is critical for us to be able to set the following against a service as we do with all our cloud resources

Application ID

Would then want to be able to build a view in pagerduty of only production services and ignore non production.
Create a dashboard for the Foods portfolio for production and then maybe one for Foods non production etc.


Reviving this thread, this is also something we need. Specifically we need at the very least the Appcode so that we can relate service/incident to our internal service catalog.

Just want check if there have been any thoughts about adding this feature. Its super valuable.


Hello @aparna.valsala & @jason.smith,

I brought this topic to the ProdDev team and they indicated that Custom Fields on Incidents in the right place to create new tags. Check out the doc:

That’s a great feature but requires that our integration populate that field on every incident. I’m suggesting that since the appcode does not change, it makes sense to be on the service itself.