DEV Community: Akshay Galande

The Hidden Tax Your On-Call Rotation Is Charging Your Team

Akshay Galande — Thu, 02 Jul 2026 06:36:06 +0000

There's a number most engineering leaders don't track: the real cost of their on-call rotation.

Not the PagerDuty bill. Not the pager pay. The actual cost — measured in burned out engineers, slower sprint velocity, compounding bugs, and the quiet resignation emails that always seem to come the month after a bad on-call week.

I've spent the last year talking to engineering teams about their on-call experience. The conversations are remarkably similar regardless of company size, stack, or industry. The pain is the same everywhere. Here's what I keep hearing.

The 62% problem

Across every team I've talked to, the rough number is consistent: somewhere between 55 and 70 percent of production pages are for issues the team has already solved before.

Not the same bug in the same service. The same pattern in a different service. A null check that was fixed in the checkout service in March pages someone in the payments service in June. A timeout retry that was handled in the API gateway shows up as a new incident in the notification service.

The knowledge exists inside the organization. It's sitting in a merged PR from three months ago. But the engineer getting paged at 2am has no way to know that. So they start from scratch. Read the stack trace. Form a hypothesis. Write the fix. Run the tests. Open a PR. Two hours later, they go back to sleep — having essentially duplicated work that already existed somewhere in the codebase.

This is the core inefficiency of on-call. Not that the problems are hard. Most of them aren't. It's that the system has no memory.

The day-after tax

The incident itself is only the beginning of the cost. The real damage happens the next morning.

The engineer who got paged at 3am shows up to standup running on four hours of sleep. They context-switch poorly. Their code quality drops. They skip the thorough review they'd normally do. They rubber-stamp a PR that introduces a subtle bug — which becomes next week's 3am page for someone else.

I call this "on-call debt." It works exactly like technical debt. Each incident doesn't just cost the time to fix it. It reduces the team's capacity to prevent the next one. And like technical debt, it compounds quietly until something breaks badly enough that leadership finally notices.

But by then, the senior engineer who could have prevented it has already accepted an offer somewhere else.

The retention problem nobody talks about

Here's the stat that should keep engineering leaders up at night: roughly one in four senior engineers say on-call is their primary reason for leaving a company.

Not compensation. Not the tech stack. Not the manager. The 3am pages.

This makes sense when you think about it from the engineer's perspective. They spent years developing deep expertise. They can architect systems, mentor juniors, and solve genuinely hard problems. And they're being woken up at 3am to add a null check.

The mismatch between their skill level and the work they're being paged for is what drives the frustration. It's not that they can't do it. It's that they shouldn't have to.

When a senior engineer leaves because of on-call burnout, the replacement cost is staggering. Six months of recruiting. Six months of ramping. A year of lost institutional knowledge. For a 10-person team, on-call-driven turnover can easily cost $200K to $300K per year in hidden replacement costs alone.

The tool chain gap

The irony is that engineering teams have never had more tools. Sentry catches the error. Datadog shows the metrics. PagerDuty wakes someone up. Slack broadcasts the alert to the whole channel.

Detect. Notify. Amplify. Human.

That's the current workflow. Every tool in the chain is doing its job. But notice what's missing: nothing in that chain does the actual work. Every tool passes the incident to the next one until a human picks it up.

We have AI that can write code, generate tests, refactor entire files. But the on-call workflow still terminates at a sleepy engineer with a laptop. The tooling around the incident is sophisticated. The resolution is still completely manual.

The split that should exist

Not every incident needs a human. That's the uncomfortable truth that the current on-call model refuses to acknowledge.

When you look at the 62% of repeat-pattern pages, these are incidents where the diagnosis is straightforward, the fix is small, and the risk is low. A null check. A timeout retry. An unhandled promise. A missing error boundary.

These don't require creativity or architectural judgment. They require pattern recognition and the mechanical work of writing a fix, running tests, and opening a PR.

Meanwhile, the other 38% — the genuinely novel failures, the cascading incidents, the architectural problems — these absolutely need a human. They need someone who understands the system deeply, can reason about edge cases, and can make judgment calls under pressure.

The split should be:

Routine incidents get handled automatically. Complex incidents get escalated to humans with full context so they can solve, not investigate.

Tier 1: automation. Tier 2: your best engineers.

This isn't a futuristic idea. It's how every other operational domain works. Customer support has had tier-1 automation for years. IT helpdesks auto-resolve password resets. Network operations centers auto-remediate known failure patterns.

Software engineering is the last holdout. And the cost of that holdout is measured in burnout, turnover, and lost velocity.

What would have to be true

For this split to work, you'd need something that can do four things:

First, it needs to understand production errors at the code level. Not just "this service is throwing 500s" but "this is a null reference on line 47 of checkout.ts because session.user can be undefined when the auth token expires."

Second, it needs pattern memory across services. If Service A fixed this exact pattern three months ago, the system should know that and apply the same approach.

Third, it needs to actually produce the fix. Not a suggestion. Not a recommendation. A working code change with tests that passes CI and is ready for human review.

Fourth, it needs to know its own limits. When the incident is too complex or the confidence is too low, it should escalate immediately with full diagnostic context — not attempt a fix it's not sure about.

This is the problem we set out to solve with BugOps. It connects to your monitoring and version control, handles the routine incidents autonomously, and escalates the hard ones to your team with everything they need to resolve quickly.

But regardless of what tool solves it, the underlying shift is overdue. Engineering teams deserve an on-call model that respects the difference between routine work and genuinely hard problems. The current model treats every incident like it needs a human. It doesn't. And the humans are paying the price.

The question I'd leave you with

Look at your team's on-call data from the last three months. Count the pages that were repeat patterns. Count the ones that were genuinely novel.

If the split is anywhere close to 60/40, your team is spending most of their on-call time on work that shouldn't require them.

The question isn't whether to automate the routine 60%. It's how long your team can sustain the cost of not doing it.

bugops.app

MCP logging and tracing using mcp-trace | ContexaAI

Akshay Galande — Sat, 12 Jul 2025 19:08:00 +0000

TL;DR: Add tracing to your MCP server in literally 3 lines of code:

import { TraceMiddleware, FileAdapter } from "mcp-trace-js";
const traceAdapter = new FileAdapter("trace.log");
const traceMiddleware = new TraceMiddleware({ adapter: traceAdapter });
// Use in your MCP server - boom, full visibility

npm install mcp-trace

Now let me tell you why this matters.

The Problem Nobody Talks About

Look, I've been there. You're building an MCP server, everything seems fine in development, then you deploy it and suddenly you have no idea what's happening. Users are complaining about slow responses, tools are failing mysteriously, and you're stuck playing detective with zero visibility into what's actually going on.

When you're building with the Model Context Protocol, you're essentially creating a black box. Sure, your server handles requests and returns responses, but what happens in between? Which tools are being called? How long are they taking? What arguments are being passed? Are there patterns in the failures?

Without proper observability, you're flying blind. And trust me, that's not a fun place to be when things go wrong at 2 AM.

That's exactly why I created mcp-trace-js.

The Adapters That Actually Matter

Here's where it gets interesting. I didn't just build one way to store traces - I built adapters for the places you're actually storing data:

File Adapter - Sometimes you just want logs in a file. Perfect for development or simple deployments.

PostgreSQL Adapter - Because your data is probably already in Postgres, and querying traces with SQL is powerful as hell.

Supabase Adapter - Same as Postgres but with all the Supabase goodness if that's your thing.

Contexa Adapter - For when you want cloud-based trace analytics without the setup headache.

Console Adapter - Pretty-printed logs right in your terminal. Great for debugging.

Multi Adapter - Use multiple adapters at once. Log to file AND database. Because why not?

The Privacy Thing

Here's something most tracing tools get wrong - they log everything by default and make it hard to exclude sensitive data. I built mcp-trace-js the other way around.

Want to log tool names but not arguments? Easy:

const traceMiddleware = new TraceMiddleware({
  adapter: traceAdapter,
  logFields: {
    tool_name: true,
    tool_response: true,
    tool_arguments: false,  // Nope, keep this private
    client_id: false,       // This too
  },
});

You control exactly what gets logged. No surprises, no accidentally logging user data you shouldn't.

Real Talk: Why This Matters

I've seen too many projects fail because the developers lost control of their systems. You build something, it works, then it scales and suddenly you don't understand your own creation anymore.

Observability isn't just about fixing bugs - it's about understanding patterns, optimizing performance, and staying in control as your system grows.

With mcp-trace-js, you can:

Debug faster - See exactly what tool calls are failing and why
Optimize performance - Identify slow operations and bottlenecks
Understand usage patterns - Know which tools are popular and which aren't
Monitor in production - Get alerts when things go wrong, not when users complain

The Technical Details (If You Care)

It's built with TypeScript, so you get full type safety and IntelliSense. The trace format is JSON, so you can query it however you want. It's composable, so you can use multiple adapters. It's configurable, so you can log exactly what you need.

But honestly? The technical details don't matter if it doesn't solve your problem. And the problem it solves is simple: visibility into your MCP servers.

Getting Started

npm install mcp-trace

Check out the examples in the repo. There's a basic usage example, an MCP server integration, and even a complete HTTP server setup. Pick what fits your use case and go.

The documentation is straightforward, the API is clean, and it just works.

Why I'm Sharing This

I built mcp-trace-js because I needed it. I was tired of debugging MCP servers without proper visibility. I was tired of guessing what was going wrong.

If you're building with MCP, you probably need this too. Don't wait until you're debugging a production issue at 2 AM to realize you need proper tracing.

The repo is at https://github.com/ContexaAI/mcp-trace-js. MIT licensed, contributions welcome, issues and PRs encouraged.

Stop flying blind. Start tracing your MCP servers properly.

Found this useful? Give the repo a star and let me know what you think. And if you build something cool with mcp-trace-js, I'd love to hear about it.

Creating Interactive Country Maps with Flutter and google_maps_flutter

Akshay Galande — Sat, 26 Aug 2023 21:04:59 +0000

If you're developing a Flutter application that requires displaying interactive maps with highlighted countries, you might be wondering how to achieve this using the google_maps_flutter package. While the package itself doesn't offer direct country coloring functionality, you can still accomplish this by overlaying polygons on the map. In this tutorial, we'll walk you through the process step by step.

Step 1: Setting Up the Project

Before we begin, make sure you have a Flutter project set up. If you haven't already, install the google_maps_flutter package by adding it to your pubspec.yaml file:

  flutter:
    sdk: flutter
  google_maps_flutter: ^2.0.10 # Check for the latest version\

Don't forget to run flutter pub get after adding the dependency.

Step 2: Creating the Map
Open your main Dart file and set up the basic structure for your Flutter app. We'll create a simple MapScreen widget that displays the Google Map.

import 'package:flutter/material.dart';
import 'package:google_maps_flutter/google_maps_flutter.dart';
void main() {
  runApp(MyApp());
}
class MyApp extends StatelessWidget {
da  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: MapScreen(),
    );
  }
}

Step 3: Overlaying Polygons
In the MapScreen widget, set up the Google Map and overlay polygons to represent countries. In this example, we'll create a single polygon to represent a country.

class MapScreen extends StatefulWidget {
  @override
  _MapScreenState createState() => _MapScreenState();
}
class _MapScreenState extends State<MapScreen> {
  GoogleMapController? mapController;
  final Set<Polygon> _polygons = {
    Polygon(
      polygonId: PolygonId('country_polygon'),
      points: [
        LatLng(51.5074, -0.1278), // Example coordinates for a country
        LatLng(48.8566, 2.3522),  // Example coordinates for a country
        LatLng(52.5200, 13.4050), // Example coordinates for a country
      ],
      fillColor: Colors.blue.withOpacity(0.3), // Set the fill color
      strokeColor: Colors.blue, // Set the border color
      strokeWidth: 2, // Set the border width
    ),
  };
  void addPoints()
   {
     for( var i=0 ; i < GeoJson.IN.length ; i++ )
     {
       var ltlng= LatLng( GeoJson.IN[ i ][ 1 ], GeoJson.IN[ i ][ 0 ] );
       point.add( ltlng );
     }
   }

  void _onMapCreated(GoogleMapController controller) {
    mapController = controller;
  }
 @override
  void initState() {
    addPoints();
    List< Polygon > addPolygon = [
      Polygon(
        polygonId: PolygonId( 'India' ),
        points: point,
        consumeTapEvents: true,
        strokeColor: Colors.grey,
        strokeWidth: 1,
        fillColor: Colors.redAccent,
      ),
    ];
    polygon.addAll( addPolygon );
    super.initState();
  }
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Country Coloring'),
      ),
      body: GoogleMap(
        onMapCreated: _onMapCreated,
        initialCameraPosition: CameraPosition(
          target: LatLng(51.5074, -0.1278), // Initial map coordinates
          zoom: 4.0, // Initial zoom level
        ),
        polygons: _polygons,
      ),
    );
  }
}

LatLng Points for India
GeoJson.dart

class GeoJson
{
 static const List IN = [
   [77.83745079947457,35.494009507787766],[78.91226891471322,34.32193634697579],
   [78.81108646028574,33.50619802503242],[79.20889163606857,32.994394639613716],
   [79.17612877799553,32.48377981213771],[78.45844648632601,32.61816437431273],
   [78.73889448437401,31.515906073527063],[79.7213668151071,30.882714748654728],
   [81.11125613802932,30.183480943313402],[80.4767212259174,29.72986522065534],
   [80.08842451367627,28.79447011974014],[81.05720258985203,28.416095282499043],
   [81.99998742058497,27.925479234319994],[83.30424889519955,27.36450572357556],
   [84.6750179381738,27.234901231387536],[85.25177859898338,26.72619843190634],
   [86.02439293817918,26.63098460540857],[87.22747195836628,26.397898057556077],
   [88.06023766474982,26.41461538340249],[88.17480431514092,26.81040517832595],
   [88.04313276566123,27.445818589786825],[88.12044070836987,27.876541652939594],
   [88.73032596227856,28.086864732367516],[88.81424848832054,27.29931590423936],
   [88.83564253128938,27.098966376243762],[89.74452762243884,26.719402981059957],
   [90.37327477413407,26.87572418874288],[91.21751264848643,26.808648179628022],
   [92.03348351437509,26.83831045176356],[92.10371178585973,27.452614040633208],
   [91.69665652869668,27.77174184825166],[92.50311893104364,27.89687632904645],
   [93.41334760943268,28.640629380807226],[94.56599043170294,29.277438055939985],
   [95.40480228066464,29.03171662039213],[96.11767866413103,29.452802028922466],
   [96.58659061074749,28.830979519154344],[96.24883344928779,28.41103099213444],
   [97.32711388549004,28.26158274994634],[97.40256147663612,27.88253611908544],
   [97.0519885599681,27.69905894623315],[97.1339990580153,27.083773505149964],
   [96.41936567585097,27.264589341739224],[95.12476769407496,26.5735720891323],
   [95.1551534362626,26.001307277932085],[94.60324913938538,25.162495428970402],
   [94.55265791217164,24.675238348890332],[94.10674197792505,23.85074087167348],
   [93.3251876159428,24.078556423432204],[93.28632693885928,23.043658352139005],
   [93.06029422401463,22.70311066333557],[93.16612755734836,22.278459580977103],
   [92.67272098182556,22.041238918541254],[92.14603478390681,23.627498684172593],
   [91.86992760617132,23.624346421802784],[91.70647505083211,22.985263983649183],
   [91.15896325069971,23.50352692310439],[91.46772993364367,24.072639471934792],
   [91.91509280799443,24.13041372323711],[92.37620161333481,24.976692816664965],
   [91.79959598182207,25.147431748957317],[90.8722107279121,25.132600612889547],
   [89.92069258012185,25.26974986419218],[89.83248091019962,25.96508209889548],
   [89.35509402868729,26.014407253518073],[88.56304935094977,26.44652558034272],
   [88.2097892598025,25.76806570078271],[88.93155398962308,25.238692328384776],
   [88.30637251175602,24.866079413344206],[88.08442223506242,24.501657212821925],
   [88.69994022009092,24.23371491138856],[88.52976972855377,23.631141872649163],
   [88.87631188350309,22.879146429937826],[89.03196129756623,22.055708319582976],
   [88.88876590368542,21.690588487224748],[88.20849734899521,21.703171698487807],
   [86.97570438024027,21.49556163175521],[87.03316857294887,20.743307806882413],
   [86.49935102737378,20.151638495356607],[85.0602657409097,19.4785788029711],
   [83.94100589390001,18.302009792549725],[83.18921715691785,17.67122142177898],
   [82.19279218946592,17.016636053937813],[82.19124189649719,16.556664130107848],
   [81.69271935417748,16.310219224507904],[80.79199913933014,15.951972357644491],
   [80.32489586784388,15.899184882058348],[80.02506920768644,15.136414903214147],
   [80.2332735533904,13.835770778859981],[80.28629357292186,13.006260687710833],
   [79.8625468281285,12.056215318240888],[79.85799930208682,10.35727509199711],
   [79.340511509116,10.30885427493962],[78.88534549348918,9.546135972527722],
   [79.18971967968828,9.216543687370148],[78.2779407083305,8.933046779816934],
   [77.94116539908435,8.252959092639742],[77.53989790233794,7.965534776232333],
   [76.59297895702167,8.89927623131419],[76.13006147655108,10.299630031775521],
   [75.74646731964849,11.308250637248307],[75.39610110870957,11.781245022015824],
   [74.86481570831681,12.741935736537897],[74.61671715688354,13.99258291264968],
   [74.44385949086723,14.617221787977696],[73.5341992532334,15.99065216721496],
   [73.11990929554943,17.928570054592498],[72.82090945830865,19.208233547436166],
   [72.8244751321368,20.419503282141534],[72.6305334817454,21.356009426351008],
   [71.17527347197395,20.757441311114235],[70.4704586119451,20.877330634031384],
   [69.16413008003883,22.0892980005727],[69.64492760608239,22.450774644454338],
   [69.34959679553435,22.84317963306269],[68.1766451353734,23.69196503345671],
   [68.84259931831878,24.35913361256094],[71.04324018746823,24.3565239527302],
   [70.84469933460284,25.21510203704352],[70.28287316272558,25.72222870533983],
   [70.16892662952202,26.491871649678842],[69.51439293811312,26.940965684511372],
   [70.61649620960193,27.989196275335868],[71.77766564320032,27.913180243434525],
   [72.8237516620847,28.961591701772054],[73.45063846221743,29.97641347911987],
   [74.42138024282026,30.979814764931177],[74.40592898956501,31.69263947196528],
   [75.25864179881322,32.2711054550405],[74.45155927927871,32.7648996038055],
   [74.10429365427734,33.44147329358685],[73.74994835805195,34.31769887952785],
   [74.24020267120497,34.74888703057125],[75.75706098826834,34.50492259372132],
   [76.87172163280403,34.65354401299274],[77.83745079947457,35.494009507787766]];
}

Step 4: Customization
You can add more polygons to represent different countries by creating additional Polygon objects within the _polygons set. Customize the coordinates, fill colors, and stroke colors for each polygon as needed.

Conclusion
While the google_maps_flutter package doesn't directly provide country coloring functionality, you can still create interactive country maps by overlaying polygons and customizing their appearance. This approach allows you to highlight countries with distinct fill colors on a Google Map within your Flutter application. With the flexibility of Flutter's UI capabilities, you can create engaging and informative maps tailored to your project's requirements.
We hope this tutorial helps you achieve your goal of displaying colored countries on a Google Map in your Flutter app. Happy coding!

How to set cookie using ExpressJS response.

Akshay Galande — Mon, 18 Apr 2022 20:03:38 +0000

What is cookie?

Cookies is simple key value pair stored by web server on clients browser to store/maintain user’s state.

How it is different from Localstorage?

Locastorage can also be used to store user’s state, but cookies has more advanced configurations like — expiration time, same site, secure flag, Httponly, etc. By using these advanced configurations we can programatically manage user’s state. It is considered that cookies are more secure than Localstorage in terms of handling user session or secret values like authentication tokens.

What is Httponly cookie?

A Httponly cookie is a simple cookie which is set by server with httponly flag as true which cannot be accessed by client side javascript.

Example

If you want to learn more, reach out to me at — https://twitter.com/akshay_nocode