Ensure production readiness

Implement with AI

Send this guide to your coding agent.

Prerequisite: Install Port MCP

Open in ClaudeOpen in CodexOpen in Cursor

Open plan mode if your tool supports it; otherwise present the plan below filled in and wait for my approval. Implement this Port guide in my org via MCP:

https://docs.port.io/guides/all/ensure-production-readiness

Read the raw markdown version at https://docs.port.io/guides/all/ensure-production-readiness.md - it contains every tab and code block without page markup.

Goal: get the guide's core flow working end-to-end in my org; adapting it to fit my existing setup takes priority over matching the guide 1:1.

Plan:
1. Confirm MCP is connected, in the right org, with sufficient permissions.
2. If the guide offers alternative implementation paths (tabs), pick the one matching my installed integrations and tools, confirm it with me, and implement only that path.
3. Diff the guide's data model (blueprints, properties, relations, workflows, actions, agents, automations, integrations, webhook data sources, secrets) against mine.
4. Propose adaptations for gaps, reusing existing blueprints/relations over guide-named duplicates.
5. Flag what needs a UI click, credential, or secret from me, testing MCP capability empirically before ruling anything out. If the guide has a "Set up via API" section, use it for anything MCP can't do before treating a step as UI-only.
6. Stop on any blocker and give me options. Approving this plan authorizes the writes it lists; pause only for writes beyond what's listed.

Build:
- Extend blueprint schema additively when upserting; don't remove or overwrite existing properties, and treat type conflicts as a blocker, not an auto-fix.
- Never print secret values into the chat or logs; ask me to set them in Port, or write them via the secrets API without echoing them back.
- List any mock data in the plan, minimal and labeled mock; once approved, seed it without re-asking, and tell me what you seeded.
- For anything the guide writes downstream (e.g. a webhook target), use a real entity, not a mock.
- For pages/widgets, use the real page identifier from the app URL, not a guessed slug.
- When you hit a UI step confirmed (not assumed) unsupported via MCP and not covered by the guide's API sections, pause, give exact clicks, then resume via MCP.
- Validate and give links after each meaningful step (only a tool-returned URL, no guessed paths); don't proceed if the last run wasn't a success.

Done:
- Run the guide's "Let's test it" steps where possible (e.g. execute a workflow test run) and confirm the expected output exists in Port.
- Summarize adaptations, seeded data, what was mocked or skipped, remaining UI steps, and how to verify.

This guide will walk you through configuring production readiness standards for your services.
You'll learn how to track metrics like on-call coverage and code ownership, and integrate them with your deployment process.

🎬 If you would like to follow along to a video that implements this guide, check out this one by @TeKanAid 🎬

Common use cases

• Platform engineers will be able to define clear policies for services, and automatically pass/fail releases accordingly.
• Developers will be able to easily see which policies are not met, and what they need to fix.
• R&D managers will have a bird's-eye view of service health and compliance.

Prerequisites

• This guide assumes you have a Port account and that you have finished the onboarding process. We will use the service blueprint that was created during the onboarding process.
• The Git Integration that is relevant for you needs to be installed.
• The PagerDuty integration needs to be installed.

Set up data model

Once both integrations are installed, they automatically enrich your Service blueprint:

• The GitHub integration creates a relation to githubRepository, adds mirror properties (such as github_readme, github_codeowners, and github_url), calculation properties (like github_days_since_last_push), and a Production Readiness scorecard.
• The PagerDuty integration creates a relation to pagerdutyService and adds mirror properties (such as pagerduty_oncall).

To track branch protection rules, you need to add two properties to the Service blueprint. These will be populated by the GitHub integration mapping configured below:

1. Go to your Builder page.

2. Find the Service blueprint and click on it.

3. Click on the {...} button in the top right corner, and choose Edit JSON.

4. Add the following entries to the properties section of the schema object:

   Branch protection properties (click to expand)

   "required_approvals_for_pr": {
     "type": "number",
     "title": "Required approvals for PR"
   },
   "require_code_owner_review": {
     "type": "boolean",
     "title": "Require code owner review"
   }

5. Click Save to update the blueprint.

Configure PagerDuty service mapping

To ensure your PagerDuty services are correctly mapped to your Port services, you'll need to configure the mapping in your PagerDuty integration. This will allow Port to automatically discover and relate PagerDuty services to your existing service entities.

1. Go to your data sources page and click on your PagerDuty integration.

   
   
   

2. Add the following mapping configuration to map PagerDuty services to your existing Port services and populate the pager_duty_service relation:

   PagerDuty mapping configuration (click to expand)

   - kind: services
     selector:
       query: "true"
     port:
       entity:
         mappings:
           identifier: .name | gsub("[^a-zA-Z0-9@_.:/=-]"; "-") | tostring
           title: .name
           blueprint: '"service"'
           properties: {}
           relations:
             pager_duty_service: .id

Matching identifiers

Make sure the identifier mapping produces values that match your existing service entity identifiers. You may need to adjust the JQ expression to match your naming convention.

Configure GitHub branch protection mapping

To populate the branch protection properties on your services, add a mapping for the branch kind in your GitHub integration:

1. Go to your data sources page and click on your GitHub integration.

2. Add the following mapping configuration:

   Branch protection mapping configuration (click to expand)

   - kind: branch
     selector:
       query: "true"
       defaultBranchOnly: true
       protectionRules: true
     port:
       entity:
         mappings:
           identifier: .__repository
           blueprint: '"service"'
           properties:
             required_approvals_for_pr: >-
               .__protection_rules.required_pull_request_reviews.required_approving_review_count
             require_code_owner_review: >-
               .__protection_rules.required_pull_request_reviews.require_code_owner_reviews

   This maps the default branch's protection rules directly onto your service entities, populating the required_approvals_for_pr and require_code_owner_review properties you created earlier.

Update your existing service's scorecard

Now that the PagerDuty and Git integration data is available on your Service blueprint, let's add scorecard rules that use it. Your Service blueprint already has a scorecard called Production Readiness with rules that check for things like a README, team assignment, and repository activity.

Let's add new rules to it that leverage the PagerDuty and Git integration data:

• Silver - the repository has branch protection enabled (required PR approvals).
• Gold - code owner reviews are required, and an on-call is defined.

Here's how to add them:

1. Go to your Builder, choose the Service blueprint, click on Scorecards, then click the existing Production readiness scorecard:

   
   
   

2. Add the following rules to the scorecard's rules array, then click Save:

   Rules to add (click to expand)

   {
     "identifier": "branchProtection",
     "description": "Checks if the repository has required approvals for pull requests",
     "title": "Branch protection set",
     "level": "Silver",
     "query": {
       "combinator": "and",
       "conditions": [
         {
           "operator": ">",
           "property": "required_approvals_for_pr",
           "value": 0
         }
       ]
     }
   },
   {
     "identifier": "codeOwnerReview",
     "description": "Checks if the repository requires approval from code owners",
     "title": "Code owner review required",
     "level": "Gold",
     "query": {
       "combinator": "and",
       "conditions": [
         {
           "operator": "=",
           "property": "require_code_owner_review",
           "value": true
         }
       ]
     }
   },
   {
     "identifier": "hasOncall",
     "description": "Checks if the service has an on-call defined in PagerDuty",
     "title": "Has on-call",
     "level": "Gold",
     "query": {
       "combinator": "and",
       "conditions": [
         {
           "operator": "isNotEmpty",
           "property": "pagerduty_oncall"
         }
       ]
     }
   }

3. Now go to your Catalog and click on any of your services.

4. Click on the Scorecards tab and you will see the score of the service, with details of which checks passed/failed:

   

Visualization

By leveraging Port's dashboards, you can create custom views to track your production readiness metrics and monitor your services' compliance over time.

Dashboard setup

1. Go to your context lake.

2. Click on the + button in the left sidebar.

3. Select New dashboard.

4. Name the dashboard Production Readiness Metrics.

5. Choose an icon (optional).

6. Click on Create.

Add widgets

In your new dashboard, create the following widgets:

Production readiness overview (click to expand)

1. Click + Widget and select Table.

2. Type Production readiness overview in the Title field.

3. Choose an icon (optional).

4. Choose Service as the Blueprint.

5. Click on Save.

6. Click on the ... on the widget and select Customize table.

7. Click on the Group by any Column icon and select Production Readiness.

8. Click on Manage properties and add the following:

   • Title
   • Lifecycle
   • Passed scorecard rule
   • Has README

9. Click on the Save icon.

   

On-call coverage (click to expand)

1. Click + Widget and select Pie Chart.

2. Type On-call coverage in the Title field.

3. Choose an icon (optional).

4. Choose Service as the Blueprint.

5. Choose Pagerduty On-call as the Breakdown by property.

6. Click on Save.

   

Branch protection status (click to expand)

1. Click + Widget and select Table.

2. Type Branch protection status in the Title field.

3. Choose an icon (optional).

4. Choose Service as the Blueprint.

5. Click on Save.

6. Click on the ... on the widget and select Customize table.

7. Click on the Group by any Column icon and select Branch Protection Status.

8. Click on Manage properties and add the following:

   • Title
   • Required Approvals (required_approvals_for_pr)
   • Code Owner Review Required (require_code_owner_review)

9. Click on the Save icon.

   

These widgets will give you a comprehensive view of your services' production readiness status, making it easy to identify areas that need attention.

Possible daily routine integrations

• Use Port's API to check for scorecard compliance from your CI and pass/fail it accordingly.
• Notify periodically via Slack about services that fail gold/silver/bronze validations.
• Send a weekly/monthly report for managers showing the number of services that do not meet specific standards.

Conclusion

Production readiness is something that needs to be monitored and handled constantly. In a microservice-heavy environment, things like codeowners and on-call management are critical.
With Port, standards are easy to set-up, prioritize and track. Using Port's API, you can also create/get/modify your scorecards from anywhere, allowing seamless integration with other platforms and services in your environment.

Related guides

• Route scorecard failures to Jira issues with AI - automatically convert failing production readiness rules into tracked, routed Jira work items.
• Auto-fix services when scorecards degrade - detect when production readiness scorecards degrade and delegate fixes to a coding agent.
• Implement the work item blueprint pattern - the ATR foundation that uses production readiness scorecards as routing gates.
• Port's OpsGenie integration - add on-call coverage data to your production readiness scorecard.
• Integrate scorecards with Slack - notify teams via Slack when services fail production readiness rules.