The Practical Guide to internal developer portals

Reporting and Executive Views

Chapter 7

Reporting is almost always treated as an afterthought in conversations about internal developer portals. 

This is a missed opportunity – but not a surprise. As we’ve discussed, one of the core goals of an internal developer portal is to improve developer productivity and autonomy. And historically, reporting (for example, views showing the adoption or maturity of different services, or DORA metrics by engineering team) are seen as catering to execs, rather than providing value to hands-on-keyboard devs. Thing is, reports can work both for execs and developers, especially if they are implemented into a personalised dashboard per developer or team, highlighting pertinent information in the portal or the catalog.

But you’re leaving value on the table if you overlook a portal’s reporting capabilities. Done right, reporting can:

  • Provide visibility into platform adoption, usage, and impact to identify areas for improvement. For example, low usage of a new API could indicate issues with documentation that need to be addressed. Reports also surface troubled services with reliability problems or ineffective tools with low ROI.
  • Highlight trends over time to inform strategic decisions. Analytics may reveal spikes in traffic to a core service, indicating a need to scale resources. Or broad adoption of a new programming language may inform training and hiring priorities.
  • Track progress on business goals like productivity, time to market, operational efficiency. Reports can tie platform metrics directly to organizational KPIs to showcase impact.
On the organizational level, strong reporting can improve the strategic impact of the engineering team by ensuring focus on the right priorities. And on the individual level, reporting can serve as a self-serve tool for developers to enhance productivity and identify opportunities for better engineering quality.

Reporting needs differ by persona

Just like a portal needs to provide dev teams with the right abstractions and self-service actions for their needs, reporting needs to be aligned to the use cases of different user “personas.” For example, the right reporting views will ensure that:  

  • Developers can self-serve reports and dashboards to optimize their own productivity. For instance, seeing traffic sources and error rates for their APIs helps improve integrations. Monitoring runtime performance aids optimization.
  • Product managers can track adoption of new tools and usage of existing features. This guides enhancement priorities and roadmaps. Low usage may indicate poor marketing rather than a bad product.
  • Executives can have dashboards that guide prioritization of technical resources based on usage, health, and business impact reports. For example, if a core payments service shows spiking errors, additional staff could be allocated to improve resilience.
  • CIOs can benchmark teams across usage of shared services, reuse of components, and productivity metrics. This highlights opportunities to promote best practices and engineering quality among groups.

Customization is critical

Customization of reporting is the key to ensuring that different personas in the organization are getting the information that’s most valuable to them – when they need it. 

Customizable reporting includes basic flexibility around elements of data reports, including:

  • Metric definitions
  • Visualizations
  • Reporting frequency
  • Supporting documentation

A platform engineering team should think of internal developer portal reporting through the product lens – with specific “customers” in the organization. (More on the product mindset and organizational adoption strategy in Chapter 9.)

Usage, health, productivity, and business impact

Once you’ve identified your primary personas for reporting and thought through the right customizations  – it's time to think about what are the most common reporting “use cases”? In other words: what are the specific operational areas that the reporting should address and actions that might be taken as a result? 

Usage reports show service adoption (e.g., how frequently APIs are called). Health reports measure the reliability and performance of services, productivity reports surface DORA metrics, and business impact reports track operational efficiency and identify the technology drivers of company-level financial performance.   Other reports can track engineering quality initiatives, such as production readiness of microservices.

The table below summarizes each report type along with representative metrics – and why they matter.

Report type Sample metrics Why it matters


  • API calls per day
  • Peak concurrent users
  • Tool adoption rates
  • Prioritize documentation/support for low-traction APIs
  • Rightsize infrastructure for highly utilized services
  • Identify unused tools to deprecate


  • Uptime/availability
  • Latency histograms
  • Error rates
  • Improve reliability for business-critical flows
  • Optimize performance bottlenecks
  • Prevent disruptions and outages

Productivity and velocity

DORA metrics (deployment frequency, lead time for changes, and change fail rates)

  • Enhance release planning and predictability
  • Address code quality issues
  • Optimize CI/CD pipelines
  • Accelerate incident response and recovery

Business impact

  • Revenue per API call
  • Release frequency
  • Mean time to resolution
  • Identify highest value-add services
  • Shorten iterations between releases
  • Improve operational efficiency
  • Enhance FinOps cost efficiency

Scorecards, discussed previously, are a critical input to reporting. A single report can draw from multiple scorecards to highlight different facets of, for example, service health. 

Particularly valuable in the context of reporting is the concept of initiatives. As laid out in Chapter 5, initiatives represent collections of scorecards that point to common strategic priorities or investments (e.g., improving reliability). Reporting and dashboards are a crucial mechanism to provide updates on progress against organizational initiatives. 

The final word

As a “single pane of glass” into a company’s applications and services, internal developer portals are uniquely situated to deliver reporting on the usage, health, and business impact of a company’s technology footprint. 

Reporting built and automated through a company’s internal developer portal has the potential to unlock efficiency, productivity, and strategic insight at multiple levels of the organization. When done right, it can guide critical decisions at the C-suite level – and give developers self-service insights into key prioritization and resource allocation tradeoffs on a day-to-day basis.

Download guide

No email required

That is how the 'info box' will look like:
Further Reading:
Read: Why "running service" should be part of the data model in your internal developer portal

Let us walk you through the platform and catalog the assets of your choice.

I’m ready, let’s start