Skip to content

SRE as a Service with 24/7 on-call

We take the pager. Engineers who know your systems respond to incidents around the clock, write honest postmortems and define SLOs your business can read.

An engineer replies, not a salesperson — within one business day.

  • 24/7 on-call
  • A runbook for every alert
  • Postmortem after every incident
  • Co-founders do the work

Official cloud partners

  • Yandex Cloud
  • Selectel
  • Timeweb Cloud
among our clients
  • Novotek
  • RZD
  • SberCorus
  • Otus
  • Besttrip
  • JedAI
  • IMSystems
  • Builddocs
  • Headframe
  • RTDS
Case studies →
symptoms.log

When teams come to us

Developers are on call and burning out

Product engineers get woken up at night and spend the next day recovering instead of building.

Monitoring pages on everything

Real incidents get lost in the noise, and the alert channel is muted.

Incidents repeat

Every outage ends with “we should fix that”, and nothing changes.

Customers notice first

You learn about outages from support tickets, not from your monitoring.

scope.md

What we do

24/7 on-call

An agreed escalation path and engineers who have onboarded on your systems before they take the pager.

SLOs and error budgets

SLIs for the user journeys that matter, so alerts fire when customers are affected, not when a CPU spikes.

Alert review

Fewer alerts, each tied to a runbook that says what to check and what to do.

Incident response

We work an incident until it's resolved and keep you updated while we do.

Postmortems

Blameless write-ups with timeline, root cause and action items that we then implement.

Capacity and peaks

Capacity planning and load testing before launches and seasonal traffic.

What you keep

  • On-call rota and escalation policy
  • SLO dashboard and a runbook per alert
  • Incident log and postmortems
  • Monthly reliability report

Stack

  • Prometheus
  • Grafana
  • Alertmanager
  • Loki
  • OpenTelemetry
  • Kubernetes
git log --cases

Similar problems we have solved

All case studies
Industrial

Novotek

Infrastructure had grown ad hoc: configuration lived on the servers, and changes could not be tracked or reproduced.

  • Described the infrastructure as code, so it is reproducible and goes through review
  • Separated development, testing and production environments
  • Introduced monitoring and an incident response procedure
Transportation

RZD

Strict continuity requirements: services cannot be stopped, and problems must be visible before users notice them.

  • Rebuilt the setup for fault tolerance with no single points of failure
  • Set up metrics, logs and meaningful SLI/SLO-based alerts
  • Organized on-call rotations and incident reviews
Telecom

RTDS

Some incidents were reported by users rather than caught by monitoring.

  • Introduced metrics, logs and traces with alerts on business-critical flows
  • Organized 24/7 on-call and incident response
  • Introduced incident reviews that fix root causes, not symptoms

TEAM.md

Who will work on your project

There are three of us, by design: the engineers you talk to are the engineers who do the work. No account managers, no hand-offs.

  • Alexander Kaloshin — Co-founder

    Alexander Kaloshin

    Co-founder

    20+ years in IT. In 2014 he founded Last.Backend, a container orchestrator built at almost the same time as Kubernetes. Leads our AI practice.

    • Last.Backend: container management and DevOps as a service
    • Fault-tolerant infrastructure: Kubernetes, CI/CD, bare metal
    • Go engineering
    • Speaker at ProIT Fest and GolangConf
  • Alexander Tikhomirov — Co-founder

    Alexander Tikhomirov

    Co-founder

    7 years in DevOps and dozens of delivered projects, from a first pipeline to production under heavy load.

    • Infrastructure design and operations
    • Cloud migrations and greenfield builds
    • CI/CD, Kubernetes, infrastructure as code
  • Denis Gerasimov — Co-founder

    Denis Gerasimov

    Co-founder

    5 years in DevOps. Takes on the hardest problems and sees them through.

    • Complex infrastructure projects
    • Monitoring, on-call and incident response
    • Operations automation
FAQ.md

FAQ

Who gets paged at 3 a.m.?
An engineer from the team assigned to you, who has onboarded on your systems. There is no generic call centre.
How do you onboard before taking the pager?
We review your architecture and alerts, write runbooks and shadow your current on-call first. We go live only when the runbooks and alerts are in place.
Do you guarantee uptime?
We agree on SLOs after observing your system for a while. Before that, any uptime number would be a guess, and we don't publish guesses.
Can we keep our own on-call and use you as a second line?
Yes. We can be first line, second line, or cover nights and weekends only.
Where is your team and what hours do you work?
We work in UTC+3. That is one to two hours ahead of Central Europe, so a normal European business day overlaps almost entirely with ours. For US teams we schedule calls in your morning, and incidents are covered 24/7 regardless of time zone.
How do you get access to our systems?
Through accounts you create for us, with MFA and least-privilege roles. Access is logged and can be revoked at any time. We sign your NDA before the first technical conversation if you prefer, and we don't copy your data to our machines.

Let's talk about your infrastructure

Tell us what is going on today. We reply within one business day with a free initial review.