Show HN: Spikelog – A simple metrics service for scripts, cron jobs, and MVPs (spikelog.com)
I built Spikelog because I kept wanting to track simple numbers over time but every time I looked at proper observability tools, I'd bounce off the setup complexity. I wanted to make something that didn't require a lot of thinking to use.
Spikelog is made to be as simple as possible:
- POST a JSON with chart name + value (you can add some tags as well but I've not tested this part works yet)
- Chart appears automatically
- 1,000 point rolling window per chart (old data expires, no retention config)
- Max 10 charts
That's basically the whole product.
I built it in about a day using Cursor. The API is intentionally minimal so AI assistants can use it too.
I have a prompt that lets your coding agent analyze a codebase and add tracking automatically (after you approve the plan).
I used it to make Spikelog track itself: https://spikelog.com/p/spikelog
There's no alerting yet (that's next), no complex aggregations, no dashboards beyond the auto-generated charts. If you need real observability use something fully featured like Axiom or Datadog. This is for people who just want to see if a number went up or down and don't want to build that themselves. i.e. they want something slightly better than just logging the number.
You can also share the charts publicly and I might add some password protection if there is demand for that.
I haven't battle-tested it under heavy load. The rolling window deletion is naive (deletes oldest points on insert). There are probably edge cases I haven't hit yet.
Would love feedback, especially if you try it and hit something broken.
7 comments
[ 4.7 ms ] story [ 30.3 ms ] threadIt seems like it's becoming the new norm. Two recent examples I've seen: Xcode ships with for-LLM xOS documentation, and Stytch provides for-LLM SDK/API documentation.
Ah, that's why it shows user count (an integer) as a floating point? Or is that an inherent limitation somehow?
I do agree that observability stacks are usually a deep pit of things to configure and services to run, but there are tools that simplify things considerably. I can personally vouch for OpenObserve, and I've heard good things about SigNoz as well. They're essentially a single-binary deployment, and all it requires is configuring otel-collector on each machine you want to send data from. I know that OpenObserve has a REST API as well, so you can just send the data via plain HTTP if you prefer to not use OpenTelemetry.
So while I'm sure your project is useful for very simple use cases, it will be difficult to support anything slightly more sophisticated. And you'll have to reinvent the wheel for most of this, of course. But good luck, regardless!
Some thoughts: 1) I think you could simplify the onboarding - I don't think I actually need to make an account up front. It somewhat contradicts the way the landing page presents things. 2) The AI prompt does a good job - I really like the output it provides. 3) It doesn't seem like there's a super straightforward way to separate local & production logs - would be nice.
I implemented it - I'll see how it cooks the next couple of days & check back.
Side note, if you want to try that project, since you're a vibe coder, I'd appreciate the feedback too - vibescaffold.dev.