Q: How quickly do you reply?

Within one business day. Office hours are Mon–Fri, 9:00–18:00 Pacific , so a message sent late on a Friday is normally answered Monday morning. The reply comes from an engineer who read the detail, not from an autoresponder.

Q: Is there a phone number?

No — email is the only route in, deliberately. Routing problems are described in prefixes, AS paths, TTL values and timestamped graphs, and none of that survives a phone call intact. Writing keeps the detail recorded, quotable and correctable from the first message. We move to video once we are talking; we just do not start there. The contact page lists what to send.

Q: What happens if the scope changes?

It usually does, because assessments find things — an undocumented peering, a transit gateway route table nobody owns. We stop, write down what it changes, and you decide whether to extend, defer, or leave it documented and untouched. Work outside the agreed scope does not start on our judgement alone.

Q: Do you work in our cloud accounts?

Yes — your accounts, your identity provider, roles your team creates and can revoke. We do not host infrastructure on your behalf or hold long-lived credentials. Assessments need read-only access to network configuration, flow logs and monitoring; implementation needs scoped write access to the networking resources involved, agreed with your security team first.

Question 1

How do I start?

Accepted Answer

Email hello@cloudroute.net with two or three lines about the symptom: what is slow, what failed over badly, or what you are about to build. Add your providers, roughly where your users are, and any figure you already measure. A p99 chart and the path a request takes is enough for us to say whether we can help.

Question 2

How quickly do you reply?

Accepted Answer

Within one business day. Office hours are Mon&ndash;Fri, 9:00&ndash;18:00 Pacific , so a message sent late on a Friday is normally answered Monday morning. The reply comes from an engineer who read the detail, not from an autoresponder.

Question 3

Is there a phone number?

Accepted Answer

No &mdash; email is the only route in, deliberately. Routing problems are described in prefixes, AS paths, TTL values and timestamped graphs, and none of that survives a phone call intact. Writing keeps the detail recorded, quotable and correctable from the first message. We move to video once we are talking; we just do not start there. The contact page lists what to send.

Question 4

Does the first conversation cost anything?

Accepted Answer

No. It is a scoping call, usually 30 to 60 minutes, so both sides can decide whether this is a routing problem and whether we are the right people for it. Sometimes the honest answer is that you need an application fix, not a consultancy.

Question 5

What happens after that call?

Accepted Answer

You get a written summary of what we think the problem is, what access we would need, and the shape of work we would propose &mdash; assessment, implementation, or advisory. If you proceed, that becomes a scoped proposal with deliverables and a timeline. Our process page walks through the phases.

Question 6

How does remote delivery work across time zones?

Accepted Answer

All work is delivered remotely, worldwide, from San Francisco. We overlap comfortably with the Americas and catch European mornings early in our day; for APAC teams we agree a fixed weekly synchronous window plus written handover notes. Cutovers run in your maintenance window with someone from our side present.

Question 7

How are engagements shaped?

Accepted Answer

Around a decision, not a duration. Most work is an assessment (we measure where the latency or fragility actually lives), an implementation (we design and build alongside your team), or an advisory relationship for teams who want a second opinion before each architectural move. The engagements page describes each shape.

Question 8

Why aren't rates published?

Accepted Answer

A published number would be wrong for almost everyone reading it. Effort depends on the providers and regions in scope, how much observability already exists, whether we may touch production or only advise, and how many teams must agree to a change &mdash; a single-region latency assessment and a four-provider failover redesign are not the same engagement. You get a figure attached to a written scope before anything starts.

Question 9

What happens if the scope changes?

Accepted Answer

It usually does, because assessments find things &mdash; an undocumented peering, a transit gateway route table nobody owns. We stop, write down what it changes, and you decide whether to extend, defer, or leave it documented and untouched. Work outside the agreed scope does not start on our judgement alone.

Question 10

Do you work in our cloud accounts?

Accepted Answer

Yes &mdash; your accounts, your identity provider, roles your team creates and can revoke. We do not host infrastructure on your behalf or hold long-lived credentials. Assessments need read-only access to network configuration, flow logs and monitoring; implementation needs scoped write access to the networking resources involved, agreed with your security team first.

Question 11

Who owns the deliverables?

Accepted Answer

You do. Diagrams, runbooks, Terraform modules, test plans and the written analysis are yours to keep, fork and reuse, with no licence back to us. Documentation lands in your repositories as we go &mdash; a handover that only happens at the end is a handover that does not happen.

Question 12

Do you sign NDAs?

Accepted Answer

Yes, routinely, and normally before the first technical call rather than after it &mdash; your paper or ours. If procurement needs a security questionnaire, send it over: we answer factually about how we handle access and data, and we do not claim audits or certifications we do not hold.

Question 13

Which providers do you work across?

Accepted Answer

AWS, Google Cloud, Azure and Cloudflare are the four we are in most days &mdash; down to Transit Gateway route propagation, Cloud Router and NCC, Virtual WAN hub design, and Cloudflare's Anycast and load balancing behaviour, plus CDN and edge platforms alongside them. Our provider notes show the level of detail we work at.

Question 14

Do you work with Kubernetes and service mesh?

Accepted Answer

Yes, where the network is the problem: ingress and gateway configuration, CNI choice and its effect on pod-to-pod paths, cross-cluster traffic, and mesh-level retries, timeouts, outlier detection and locality-aware routing in Istio or Linkerd. If the question is operator design or cluster lifecycle, we are the wrong specialists &mdash; Kubernetes networking shows where we draw the line.

Question 15

Do you write Terraform?

Accepted Answer

Yes. Routing changes that exist only in a console drift within weeks, so what we build is code in your repository, in your module conventions, reviewed through your normal pull request process. If you use CloudFormation, Pulumi or CDK, we work in that instead. If networking has no IaC yet, we codify what exists first.

Question 16

Do you take on BGP and Anycast work?

Accepted Answer

Yes &mdash; it is the core of what we do: ASN acquisition and RIR paperwork, prefix planning, peering and IX strategy, policy design using communities, AS-path prepending and MED, RPKI and route origin validation, and Anycast for DNS and edge services. See cloud routing consulting and our BGP guidelines .

Question 17

What if the real problem is in the application?

Accepted Answer

We tell you, with the evidence, and stop billing for network work that will not help. Expect it sometimes: an N+1 call pattern across regions, TLS handshakes not being reused, a synchronous cross-region write on the request path. Measurement is good at proving where time is not spent, which is useful even when the fix belongs to your application team.

Question 18

Can you help during an active incident?

Accepted Answer

Sometimes, and we would rather state the limit than sell a promise we cannot keep. We are a small specialist team without a 24/7 rota, so a cold page at 02:00 on a Sunday may not reach an engineer. Clients in an active advisory relationship, whose architecture we already know, get a documented escalation path and a far faster answer &mdash; the slow part of incident help is understanding an unfamiliar topology, not typing. If you need guaranteed round-the-clock cover, buy it from a managed provider.

Question 19

Do you guarantee a latency or uptime figure?

Accepted Answer

No, and be sceptical of anyone who does. We do not control the transit providers, peering disputes or provider control planes between your users and your origin, so a contractual millisecond number would be a claim about someone else's network. Instead we agree explicit targets up front &mdash; a p99 ceiling for a named user population, an RTO and RPO for a region loss &mdash; then measure the same way before and after, and report the result even when we miss. Our results page explains how we frame outcomes.

Question 20

How are changes rolled back?

Accepted Answer

Every change is planned with its reversal written first, and the plan states how long that reversal takes to propagate. The distinction matters: a weighted DNS shift reverses at the speed of your TTL, a BGP withdrawal propagates in minutes but not uniformly, a route table entry reverses immediately. Where reversal is slow we lower TTLs days in advance. Anything in Terraform reverses through a revert commit your team can apply without us.

Question 21

How do you avoid taking production down?

Accepted Answer

By never making a change that is simultaneously large, unmeasured and irreversible. Reproduce the path in a non-production account or a spare prefix; shift a small weighted percentage of real traffic and watch p99 and error rate before widening; hold an agreed abort condition and a named person who can call it. Failover is tested by inducing the failure deliberately in a controlled window, rather than learning mid-outage that the health check was probing the wrong port &mdash; much of our reliability and failover work.

Frequently asked questions

Working with us