Thanks for joining us at our live conversation with Spotify Backstage to discuss the new PagerDuty plugin.
We weren’t able to answer all your questions live, so we’re adding all the Q&A to this thread for your convenience. Feel free to ask additional questions below!
Question 1: Do we have the full scale service maps coming across from backstage to PagerDuty for better service support framework & health & impact view of dependent services?
- Answer: We have Backstage integrated with PagerDuty, syncing our service dependency maps to power Service Graph and impact chains.
- Not a full “all-things” topology import: You’ll still manage Business Service structure and any non-service entities in PagerDuty for the best health/impact views.
Question 2: Is there a difference in functionality between the PagerDuty plugin for Backstage and the one for Portal?
- Answer: There are no functional differences. It’s the same PagerDuty plugin and feature set in both.
Question 3: Is there any video to integrate insights plugin in Backstage?
- Answer: There isn’t a public, step‑by‑step video specifically for integrating the Backstage Insights plugin today. The official guidance is currently in written form in the Backstage Insights docs (part of the Spotify Plugins for Backstage bundle) https://backstage.spotify.com/docs/plugins/insights/setup-and-installation
Question 4: How do I scale Backstage for multiple customers or clients? Use an instance per client or use something like namespaces for that?
- Answer: Backstage is fundamentally single-tenant, so the cleanest way to serve multiple external customers is: Run a separate Backstage instance per customer.
- This gives strong isolation (data, auth, config) and keeps compliance/simple support boundaries clear. Using “namespaces” or soft multi‑tenancy inside one instance is possible but requires a lot of custom work (tenant-aware auth, catalog filtering, and permissions) and is usually better suited to separating internal business units, not different customers. So for you as a customer: we recommend one Backstage instance per client.
Question 5: How does the PagerDuty plugin handle integrating with Backstage if there are conflicts between the two service graphs?
- Answer: The PagerDuty plugin supports only a 1:1 mapping today (one Backstage entity → one PagerDuty service). It does not attempt to merge or reconcile the Backstage catalog graph with the PD service graph. Backstage remains the source of truth for catalog structure; the plugin reads and displays PD data for the mapped service.If there are conflicts, the plugin won’t rewrite either side. The recommended approach is to:
- Keep a single PD service ID annotation per Backstage entity.
- Resolve duplicates or unmapped services in the catalog/PD directly.
- If you need alignment between dependency graphs, handle that via a separate sync/report job outside the plugin.
Question 6: How do I integrate PagerDuty into Backstage, can you provide an end to end guide or steps?
- Answer: Here are two guides to get started: https://support.pagerduty.com/main/docs/backstage-integration-guidehttps://pagerduty.github.io/backstage-plugin-docs/getting-started/pagerduty/
If you missed the session or want to rewatch insights, you can find the recording here: https://www.pagerduty.com/resources/integrations/webinar/incident-management-inside-your-developer-portal-pagerduty-spotify-portal-for-backstage/