Why AlertKick is opinionated, not configurable
Every knob in a monitoring tool is a decision somebody has to make. Most of those decisions have a right answer. AlertKick ships the right answer by default - so you don't have to be the person figuring it out.
Sandeep Sidhu · Founder, AlertKick
Most monitoring tools are proud of being configurable. They hand you a rules language, a query DSL, a templating system, a plugin framework, and an invitation to make it yours. The marketing copy talks about flexibility and power.
In practice, configurability means day one is a blank screen and day 180 is a sprawling rules repository that only two people understand.
Plenty of teams have done both halves of that. None of them enjoyed it. AlertKick ships with opinions.
What “opinionated” actually means here
“Opinionated” here means three specific things.
One: the right checks are on by default.
You install the agent on a Linux host. Within a minute, we know what’s running on the box - systemd units, Docker containers, exposed ports, common services. The checks you should have on day one are now running. Not a templated starting point you have to customise - just running.
If you’re on a fresh Ubuntu server with Postgres and nginx, we’ve already started watching disk, memory, CPU, system load, systemd unit health, Postgres process health, nginx health, and the ports those services bind to. The thresholds that matter are the thresholds you’d have picked anyway.
If you disagree with one of those defaults, you can change it. But you shouldn’t have to in order for monitoring to be useful. On day one, it should just work.
Two: the number of knobs is deliberately small.
For every feature in AlertKick, there’s a short list of things you can customise, and a long list of things you can’t. That’s not a limitation of the product - it’s the product.
Take alerting. You can set a severity, a channel, an escalation policy, and a silence rule. That’s the whole surface. You can’t write a templated DSL that transforms alert payloads. You can’t chain four conditional rules together. You can’t reshape the schema with jq.
That is less flexible than the tools that let you do those things. It is also less capable for the people who need those things. But those people have the budget and headcount to buy and operate a tool built for them. The cost of building all that flexibility into a product aimed at teams who’d rather not operate one is that those teams get a product they can’t operate.
We chose the teams who’d rather run their product than their monitoring.
Three: the opinions are informed, not arbitrary.
Every opinion baked into AlertKick comes from years of SRE work. Not from market research, not from focus groups, not from what another tool does. From the checks that actually caught incidents and the alerts that actually mattered.
That experience is the product. The agent installs in about a minute. What it does in that minute is worth more than the minute.
Knobs are a tax
Every option in a monitoring tool is a decision deferred.
Shipping a choice moves the work from your engineering team to your customer’s. Your team can research once, decide once, and apply the decision to every customer. The customer has to learn the context, research the choice, and make the decision themselves.
That transfer is enormous. Every knob becomes a support ticket, a forum question, a Stack Overflow thread, a bad default discovered in a post-mortem, or a blog post titled “N Things to Configure in [Tool] Before You Go to Production”. That blog post shouldn’t need to exist. The tool should just be right.
What we actually let you configure
- Which hosts are in which groups. Production versus staging, by region, by team.
- Which checks are enabled. We turn the right ones on by default. If you want to disable one, you can. If you want a custom check for something only you know about, you can add one.
- Who gets paged, when, and how. Escalation policies, on-call schedules, quiet hours, severity overrides.
- Silence rules. Maintenance windows, known-noisy periods.
- Thresholds, where reasonable. Disk full at 85% or 90%. CPU load over 1-minute or 5-minute. The number is yours if you care about it; the fact that we’re watching is ours.
The list is short because we think the right defaults have been chosen, and because the things that are different for you are the things worth you changing.
What this means for the DIY path
Running a hand-rolled stack means metrics exporters feeding a time-series database, a ruler evaluating alert expressions, a router dispatching to chat channels, a separate cron-monitoring component, a separate on-call scheduler, and a synthetic-uptime tool. Each component is configurable because they don’t know what they’re being stitched into.
Configurability creates a glue tax. Somebody on your team owns the glue. They make the opinionated decisions for you. That person is your opinionated monitoring tool - they just happen to be a person you have to pay, manage, and hire a backup for when they go on holiday.
AlertKick takes that role on a subscription. That’s not a slight at your monitoring engineer. It’s a recognition that most teams don’t have one, and shouldn’t need one.
The shape of the rest of the blog
The rest of the product shows how this opinion works in each feature:
- Infrastructure monitoring: which checks we ship by default and why.
- Heartbeats: how grace periods and intervals are chosen, so you don’t have to.
- Alerting and on-call: the escalation levels that come out of the box, and what each one is for.
- eBPF security: the detections we enable without asking you to build a ruleset.
- MCP: how AI assistants can query everything above, in natural language.
Each of those is getting its own post in the coming weeks. If you want to skip ahead and try the product, get started here.
Frequently asked questions
- What does it mean for a monitoring tool to be opinionated?
- In AlertKick's case it means three specific things. The right checks are on by default rather than offered as a template to customise. The number of configurable knobs is deliberately small, with a short list of things you can change and a long list you cannot. And the opinions are informed by years of SRE work - the checks that actually caught incidents and the alerts that actually mattered - not by market research or by copying another tool.
- What does AlertKick monitor by default after installing the agent?
- Within about a minute of installing the agent on a Linux host, it discovers what is running - systemd units, Docker containers, exposed ports, and common services - and turns on the checks you should have on day one. On a fresh Ubuntu server with Postgres and nginx, that means disk, memory, CPU, system load, systemd unit health, Postgres and nginx process health, and the ports those services bind to, with thresholds you would have picked anyway.
- What can you actually configure in AlertKick?
- The list is short. Which hosts are in which groups, such as production versus staging or by region or team. Which checks are enabled, including disabling defaults or adding a custom check for something only you know about. Who gets paged, when, and how - escalation policies, on-call schedules, quiet hours, and severity overrides. Silence rules for maintenance windows and known-noisy periods, and thresholds where reasonable, such as disk full at 85 or 90 percent.
- What can you not configure in AlertKick?
- For alerting, the whole surface is a severity, a channel, an escalation policy, and a silence rule. You cannot write a templated DSL that transforms alert payloads, chain several conditional rules together, or reshape the alert schema with jq. That is less flexible than tools that allow those things, and less capable for the people who need them - and it is intentional.
- Why are configuration options described as a tax?
- Every option in a monitoring tool is somebody's decision deferred to the customer. Shipping a choice moves the work from the vendor's engineering team, who could research and decide once for every customer, to each customer's team, who must learn the context and decide themselves, forever. In aggregate every knob becomes a support ticket, a forum question, a bad default discovered in a post-mortem, or a blog post about what to configure before going to production.
- Is AlertKick a fit for teams that need heavy customisation?
- No. Teams that need a rules language, payload transformation, or deep conditional routing have the budget and headcount to buy and operate a tool built for them. AlertKick is built for teams that would rather run their product than their monitoring, and takes on the role of the engineer who would otherwise own the glue between a DIY stack's components, on a subscription.
