24/7 Kong Support with a 15-Minute Emergency SLA

Our Kong support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, plugin chain and latency tuning, upstream and health check design, authentication and TLS configuration, cluster and hybrid mode operations, and version upgrades. Every ticket is handled by a named senior engineer assigned to your account — there is no tier-1 triage layer and no per-incident charge.

The most common cause is DNS caching. Kong resolves upstream hostnames and caches the result for the record TTL, so in an environment where backend addresses rotate faster than that TTL — pods rescheduling, instances replaced — Kong keeps dialling addresses that no longer exist while a manual curl from the same host succeeds. The second cause is health check configuration: with only passive checks, an ejected target is never re-probed and stays out of rotation. Both are configuration fixes rather than capacity problems.

Almost certainly the local rate limiting policy on a multi-node cluster. The local policy keeps counters in each node's own memory, so with N nodes behind a load balancer you effectively enforce N times the limit you configured. Moving to the cluster or redis policy gives shared counters across nodes. Redis is generally the right answer at scale, and we size and configure it as part of the change rather than just flipping the setting.

Yes. Kubernetes is where most of our Kong work sits. We handle ingress class configuration, KongPlugin and KongClusterPlugin resources, namespace scoping, reconciliation failures that appear as silent no-ops, and the interaction between the controller's declarative config and the gateway's runtime state. We also support hybrid mode deployments where the control plane and data plane are split across clusters.

Yes, and we will be direct about whether you should. DB-less removes an operational dependency and suits GitOps-managed config, but gives up runtime-created consumers and some plugin state. Hybrid mode keeps a database at the control plane while data planes run from cached config, which is usually the right answer for large multi-region estates. We plan and execute the migration with a parallel-run validation step rather than a cutover weekend.

Yes, both, including the awkward middle ground where a customer is on OSS and evaluating whether the Enterprise features — RBAC, Dev Portal, advanced plugins, vendor support — justify the cost. We will give you a straight answer based on what your team actually needs rather than pushing an upgrade.

Under Kong's support policy, each Kong Gateway Enterprise minor version is supported for one year and each LTS version for three years, with a 12-month sunset period afterwards; Kong Gateway Enterprise 3.10 and 3.14 are the current LTS releases. The policy and its supported-version table apply to the Enterprise product. Kong Gateway OSS, the community edition, has no LTS and no support period from Kong, which is a frequent question on the project's GitHub. AceMQ covers both editions on any version, including Enterprise releases in sunset and OSS releases the community has moved past, and plans the upgrade to a supported version as part of the engagement.

Yes. Kong Konnect is Kong's hosted control plane: Kong runs the management layer, the service catalog and the developer portal, while the data plane gateways still run in your own infrastructure and remain your responsibility to keep on a supported version. We cover those gateways, the plugins configured on them, and the APIs behind them. On the developer side that means the decK declarative configuration and CI pipeline, custom plugins written in Lua or against the plugin development kit, and the OS and Kubernetes platform the gateways run on, so a rate limiting or authentication problem is traced through the whole path rather than stopping at the Konnect console.

Yes, and the router change is the main risk. From Kong Gateway 3.0, a route path is treated as a regular expression only if it starts with the ~ prefix, and every other path is matched as plain text, so regex routes carried over unchanged stop matching. For declarative configuration, deck file convert adds the prefix. We also review plugin and configuration changes between your version and the target, then run a rolling upgrade with a tested rollback.

Kong's own support handles defects in Kong Gateway Enterprise and Konnect on supported versions. It does not design your plugin chain, debug the upstream services behind the gateway, or fix the Kubernetes and network configuration around it. AceMQ Kong support covers that layer with a 15-minute emergency response, works alongside your subscription rather than replacing it, and hands Kong a diagnosed case when a fault turns out to be in the product.

Yes. AceMQ works on Kong in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your Kong environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Kong is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.