Continuous testing for every background job you run.
Kerno triggers each task through your own broker, the way your app does, and verifies what it changed.
Faster merges, with every background job verified.
6×
Faster merges for PRs tested by Kerno
72%
Of planted runtime bugs caught across real open-source backends
11 of 14
Critical-severity bugs caught across 7 open-source backends
11 of 14
State bugs caught, from dropped fields to dead reset links
Agents and engineers at these companies use Kerno
Kerno was up and running in minutes with no manual work, and it made our API migration so much smoother. We could instantly validate that every change made by Cursor worked the way we expected, and now it’s a core part of how we build.
Misch StrotzCo-Founder & CEOUsing Kerno with Claude Code has been a game changer. You get quick feedback with no manual effort, and it saves you a lot of time and hassle debugging integration issues post-merge.
Jonathan BernalesCTOKerno saves us a lot of manual work and helps us catch side effects and issues that would definitely break our projects’ backends. Our engineering team loves it.
Santiago J. VallsCo-Founder & CTORegressions have always been a huge bottleneck for our team. Kerno has been a force multiplier helping us ship releases much faster without the manual overhead of QA.
Ronan HigginsCTOKerno triggers async work the way your app does, then verifies what it changed.
Consumer discovery
Celery tasks, Graphile Worker jobs and scheduled work each become their own subject, with their own scenarios.
Dispatch through your broker
Kerno publishes to Redis, RabbitMQ or your own Postgres job queue, the same path your application uses.
Unresolved wiring reporting
A dynamic task name or a queue resolved at deploy time is reported with the reason, and never guessed.
Store and message assertions
Kerno reads the rows a job wrote and subscribes to what it published, then checks both against the run.
Per-run data isolation
Each scenario arranges its own rows and its own correlation id, so a scheduler firing mid-run cannot skew it.
Job behavior drift
The assertions from the last run are the baseline, so a changed outcome or payload shows up as a diff.
Catches failed jobs, missing writes and payload drift across every worker.
Task execution
Terminal state, task outcome, and the work a job actually did.
Queue messages
Consumer handling, message payloads, and chained task dispatch.
Scheduled jobs
Beat entries, cron registrations, and the task behind each one.
Store writes
Rows created, updated and removed, checked against your own schema.
Published messages
Payloads a job emits, the queues it lands on, and their shape.
Idempotency
A repeat dispatch, and whether the same effect lands twice.
Python
TypeScript
JavaScript
Redis
RabbitMQ
AWS
Azure
PostgreSQL
MongoDB
Kerno applies your rules and standards to every job it plans and tests.
Reads your rules and standards in plain English
Write a rule the way you would explain it to a new engineer, and scope it to the repositories and paths it applies to.
Works from the context your team already wrote
Agent instruction files, service READMEs and the docs in your repository shape how every job gets tested.
Gets more accurate with every run you review
Kerno learns from each run and the feedback you give it, and carries what it learns into the tests that follow.
01How does Kerno test a Celery task?
Kerno discovers the task, triggers it by publishing to the broker the way your app does, and verifies the rows it wrote and the messages it published.
02Does Kerno test queue consumers?
Yes. Kerno discovers queue consumers and tests how they handle messages, including the rows and messages they produce.
03Can Kerno test scheduled or cron jobs?
Yes. Kerno reads your beat entries and cron registrations, then tests the task behind each one by dispatching it the way the scheduler would.
04How does Kerno trigger a background job?
By publishing to the broker, the same path your application uses, so the job runs the way it does in production.
05Which task frameworks does Kerno support?
Celery on Python and Graphile Worker on TypeScript and JavaScript, each triggered through your own broker. SQS handlers declared in a serverless manifest are discovered with their queue and arguments.
06Does async testing run in CI?
Yes. Committed scenarios replay in CI on every change.