Engineering stories,
not just project names.

The app I programmed. Choose an exercise and enter the training date, weights and repetitions for each set directly in the app. The saved sessions form the basis for its history, volume calculations and progress charts. The public Kraftwerk page is a read-only presentation of this training history. Read how Kraftwerk began →

Data with context. Session metrics, total volume, steps, and time-range controls make individual workouts meaningful within weekly and monthly patterns.

Built to evolve. CSV and health-data imports keep historical information portable, while the presentation layer can gain new metrics without rewriting the underlying records.

KRAFTWERK / MISSION LOG

From paper to progress.

Four stops in the story of an app built around my own training.

01The notebook02Digitisation03My own app04Progress today

Stop 1 / 4

It started with a notebook.

I could not find the right training app. So I wrote down dates and repetitions by hand. This is my original push-up page.

A small setup with a growing blind spot. At the beginning there were only a handful of servers and scripts analyzing log files. As the platform grew, that approach could not keep up with either scale or complexity. More importantly, it was reactive: it told us what had already happened.

The boss and the customer are not monitoring tools. Why wait until a problem has happened to notice it? If a manager or a customer is the first to report an outage, operations is already behind. Beyond the incident itself, that puts confidence in the team at risk—inside and outside the organization.

The classic example: an expiring TLS certificate. In 2000, the certificate-renewal automation familiar today was not available in the same form. Let’s Encrypt arrived much later, in 2015. We needed to monitor approaching expiry rather than discover it through a broken connection. Certificate requirements and issuers can vary; even an automated renewal process needs to be monitored.

Detect, notify and keep the evidence. Our first choices were Nagios and Zabbix. We needed checks that detected problems and notifications that reached someone able to act. Notifications went especially to the 24/7 on-call responder team, so incidents could be acted on around the clock. At that time, cost constraints meant the website did not yet have a high-availability architecture. Reliable detection and rapid response were therefore central to maintaining the best possible service quality; monitoring did not itself remove the risk of downtime. Over the years, delivery channels included SMS, WhatsApp and PagerDuty; these were later developments, not a claim that all of them were used in 2000.

From incidents to trends. Recording performance metrics made it possible to look beyond a single alarm: how were load, latency and available capacity developing over time? Grafana and Checkmk later joined the toolset. The goal remained the same: identify deterioration earlier and use the data to understand where the system was heading.

The principle that stayed. Monitoring is not just a collection of dashboards. It should give the team a chance to act before someone else has to tell them there is a problem.

Historical reference: Let’s Encrypt’s first public certificate announcement (2015).