When the dashboard is not the real problem

Troubleshooting · Data Platforms · Reporting Reliability · AWS

Reliable reporting starts before Power BI.

I help teams investigate why reporting systems stop being reliable: scattered data, manual processes, fragile pipelines, unclear ownership or cloud costs growing without explanation.

Trustworthy dataStable pipelinesReporting that scalesVisible costs

I get into the data mess

The visible problem is rarely the real problem.

I come from support, networking and production applications. That helps me investigate live systems: I do not only look at the report, I look at sources, processes, infrastructure, costs, ownership and how the team operates.

Investigation map

01

Sources

Databases, APIs, files

02

Processes

Loads, rules, checks

03

Model

Metrics and analytics layer

04

Report

Power BI, KPIs, usage

The goal is not to blame the visible tool. It is to find where the flow breaks.

When I can help

  • The report fails, takes too long or people do not fully trust the numbers.
  • The process depends on Excel, manual steps or knowledge that lives with one person.
  • Costs, errors or bottlenecks appear but nobody can fully explain them.

Target outcome

Move from firefighting data issues to clear, maintainable and trustworthy processes.

Working principle

Most data problems are not where they appear.

A slow dashboard, an unexpected cloud bill or a manual reporting process is usually a symptom. The real cause often lives in another layer of the system.

Visible problem → Likely real cause
Slow dashboard
→
Analytical model, heavy queries or a warehouse not designed for consumption
High AWS bill
→
Network path, invisible traffic or a service using the wrong route
Manual reporting
→
Process design issue, duplicated logic or unclear ownership

The work starts when we stop looking only at the visible tool and trace the full flow: data, transformations, infrastructure, ownership and consumption.

Technical investigations

Investigation 01

From Power BI bottlenecks to a warehouse-first architecture

Symptom: The visible issue was slow refreshes. The real issue was transformation ownership living inside the BI layer.

Investigation: Traced source queries, Power Query transformations and gateway constraints before moving business logic into Python ETL + PostgreSQL models.

Result: Power BI became a consumption layer instead of the place where core analytical logic lived.

  • Warehouse-first
  • PostgreSQL
  • Power BI
  • ETL
  • Python
Read investigation →

Investigation 02

Why a NAT Gateway suddenly processed ~10 TB/day

Symptom: A cloud cost spike looked like an application issue, but the root cause was a routing path between Loki and S3.

Investigation: Correlated CloudWatch NAT traffic with pod-level Prometheus metrics, isolated Loki and validated the S3 route.

Result: An S3 Gateway Endpoint removed the expensive path and turned the investigation into a reusable FinOps pattern.

  • AWS
  • FinOps
  • Kubernetes
  • Loki
  • Networking
Read investigation →

Investigation 03

Low-cost static hosting architecture for a real business

Symptom: A traditional business needed a professional web presence without adding operational weight or monthly platform cost.

Investigation: Used static hosting with S3, Cloudflare and Terraform, keeping the origin restricted and the delivery path simple.

Result: Fast, secure and maintainable hosting with practically zero operating cost.

  • AWS S3
  • Cloudflare
  • Terraform
  • Static Hosting
  • Security
Read investigation →

How I think

How I investigate systems

I treat data problems like system incidents: first separate symptom from cause, then trace the flow until the reliability failure becomes visible.

  1. 01

    Visible symptom

    What business sees: slow dashboard, inconsistent KPIs, high costs or unstable refreshes.

  2. 02

    Trace the flow

    Sources, transformation, infrastructure and consumption. Data changes shape at every layer.

  3. 03

    Find operational friction

    Manual processes, duplicated logic, unclear ownership, expensive routes or weak validation.

  4. 04

    Reduce complexity

    Solve with simplification, automation or a targeted redesign. Do not add complexity by reflex.

About

I'm Luis Iván Payero, but most people call me Luigi. I come from support, networking and production incidents. That changed the way I work with data.

I learned to look at live systems: what changed, what depends on what, where the flow breaks and who needs to operate the solution later. That experience matters when a report fails, a pipeline breaks or a cloud cost appears without explanation.

My focus is not only building pipelines. It is understanding why a system stopped being reliable and leaving behind a clearer, maintainable and operable architecture.

Luis Iván Payero

Technical stack

AWS, PostgreSQL, Python, Airflow and Power BI when they help solve the right problem.

I do not use tools as identity. I use them when they reduce risk, clarify ownership or make the system more operable.

  • AWS
  • PostgreSQL
  • Python
  • Airflow
  • Power BI
  • SQL
  • ETL
  • FinOps
See cases

Real delivery

Other digital projects

Small projects where the value was shipping something simple, clear and useful. This is not the center of the site; it only shows the ability to turn a real need into production.

Casa Lucho — professional painter

Problem: A painter needed a professional web presence to show work and capture inquiries without adding operational cost.

Solution: Static architecture with S3, Cloudflare and Terraform.

Result: Fast, easy to maintain and practically zero-cost hosting.

View live site →

Diego Rago — pixel artist

Problem: A pixel artist needed a portfolio to showcase work and style with strong visual focus.

Solution: Lightweight landing page with a clean gallery and clear contact.

Result: An online presence focused on the work itself, no noise around it.

View live site →

Richard Scobar — tattoo studio

Problem: The studio needed to explain style, work and contact clearly.

Solution: Direct structure, visual content and a simple CTA.

Result: Less friction for real inquiries.

View live site →

Next step

Is something breaking before data reaches the report?

Send me what is happening: which report is slow, which process breaks, which number does not match or which cost appeared. We can look at it calmly and find where the bottleneck may be.

You do not need a formal brief. A clear description of the current problem is enough.

Tell me what's failing Message me on LinkedIn