The Post-Mortem: 2024 vs. 2025
“System Health” table for my running for this year compared to last year.
| Metric | 2024 (Baseline) | 2025 (Current) | Variance |
|---|---|---|---|
| Active Days | 197 | 157 | -20% (Availability Drop) |
| Total Miles | 1,145 | 1,057 | -8% |
| Avg. Miles/Run | 5.8 | 6.7 | +15% (Heavier Load) |
| System Status | Stable | Plantar Fasciitis (Hardware Failure) | – |
In 2024, I was running at high availability (197 days). By 2025, my ‘uptime’ dropped to 157 days, but my ‘load’ per active day actually increased. I was pushing 6.7 miles per run compared to 5.8 the year before. My system was under-provisioned for the load I was giving it.
First few positives: I was able to finish a marathon closer to 5 hour limit last year October. Super exciting and signed up for 4 marathons for the year 2025. I started the year with Big Sur. Awesome and loved the race.
Continued the energy finished the year with 3 more, Grandma marathon (MN), Monumental Marathon (IN) and BMW Dallas (TX). Finishing all the 4 races, with a total of 105 race miles.
When A Sub‑4:30 Dream Meets Plantar Fasciitis
During the training came the injury, first I did not know much about it, was getting curious on the issue. At first it felt like “normal” post‑long‑run soreness. A dull ache under the heel when I got out of bed, that classic first‑few‑steps limp. A week later, I was doing the same limp every time I got up from my desk.
As always, I did what every modern runner does: I asked Google what was happening to my foot. That rabbit hole ended in a new term for my vocabulary—plantar fasciitis.
I aimed for a sub‑4:30 finish. I ended up consuming inspirational blogs. One of these was about using ChatGPT to train for the Boston Marathon. Strava, Garmin, and my favorite guru app, Run with Hal, all explain how to get faster. I did not find a clear way to change my training once I was injured. This absence was notable, especially for common issues like plantar fasciitis. Yes, YouTube is full of rehab exercises. Yet, almost nothing integrates those rehab constraints into a day‑to‑day training plan. The hardest part wasn’t the pain. I was watching my predicted finish time slide from the 4:30s to the 5s. Then it flirted with 6 hours.
I’m not a professional athlete. I’m the guy you stare at on the trail, wondering why I’m putting myself through this. But even with a ‘sub-4:30’ dream, I ran into a hardware failure I couldn’t ignore: my injuries. Every running app encouraged me to keep going. They urged me to reach my marathon goal. Yet not one ‘read the logs’ of my physical pain.
Trend Analysis- Great Pivot- Visualizing the Structure Failure
Here a chart of all the activities that I have recorded for the year 2025. As a systems architect, I’m used to looking at dashboards. If my feet were a Kubernetes cluster, October 2025 would have triggered a Critical Alert.
The Maintenance vs. Production Trend
| Month | Running (Production) | Gym/Rehab (Maintenance) | Status |
|---|---|---|---|
| Jan – Sep Avg | 13.0 | 2.3 | Healthy |
| Oct 2025 | 8 | 10 | System Pivot (Injury Peak) |
| Nov 2025 | 7 | 5 | Degraded Mode |
| Dec 2025 | 5 | 5 | Recovery / Minimal Throughput |
Designing an Injury‑Aware Coach with Spring Boot and AI
That gap is why, over the past year, I’ve been quietly building a small Spring Boot + AI application. It helps runners like me answer a much less glamorous question. “Given my current injury and fatigue, what’s the safest way to keep training?”
So instead of asking, “Can AI train me for Boston?”, my experiment became: “Can I use Spring Boot and Spring AI to build a coach? This coach would refuse to push me when my body seeing some red flags.”
I started logging pain level, sleep, and stress into my Spring Boot + AI app before each key session. The plan stopped being “What do I want to run?” It became “What does my current body state allow me to run?” The app regularly downgraded my planned long run from 16 miles to 10 easy miles. On weeks where pain and fatigue spiked, it added cross‑training.
Where You Can Try This (Or Steal the Idea)
My intention for the next 2-3 posts is clear. I want to enhance what I worked on last year. I used a stack of microservices. Additionally, I plan to add the Spring AI part. Here is the high level mermaid diagram
In my previous post on Scalable Queues, I talked about managing event-driven systems. I realized I needed a similar architecture for my health. I needed an AI Advisor that sits on top of my run-data queue. This advisor looks at my injury history to understand the context. It then decides if the ‘system’ needs a forced reboot, which means taking a rest.
The first two parts of the flow diagram were discussed with microservices. They were parsing Strava/Garmin data. The parsed data was then evented into Rabbit MQ. In the next post, we will start diving more into the implementation of the project.
Have you ever watched a race goal slip away because of an injury? It could be plantar fasciitis or something else. I’d love to hear your story. Would you trust an AI‑powered “injury‑aware coach” to tell you when to back off? Or do you prefer a human voice? What did you wish your training app or coach had done differently once you got hurt?
More to come.
Sathish Jayapal 