Incidents and maintenance reported on status page for Quonfig https://status.quonfig.com/ https://d1lppblt9t2x15.cloudfront.net/logos/7459b710ddfb21019d8da6e16588c912.png https://status.quonfig.com/ en https://status.quonfig.com/incident/1107125 Wed, 28 Oct 2026 21:33:00 -0000 https://status.quonfig.com/incident/1107125#9d8381a9b036627d262a8342eece9aacce953987ea84a573596b3d6e86ed3ba6 Incident Resolved. We released a fix at 21:33 UTC, and the app is reading and writing configuration normally again. This was a minor incident limited to the Quonfig app; config delivery and flag evaluation were not affected at any point. We are adding monitoring so a problem like this is caught before it reaches production. https://status.quonfig.com/incident/1107125 Wed, 28 Oct 2026 20:42:00 -0000 https://status.quonfig.com/incident/1107125#079008f1599ccd211afd92b26796fd39e79b677053f324214c998b3e84fb92bb Incident Starting at 20:42 UTC, a routine upgrade of the Quonfig app's base image stopped the app (app.quonfig.com, plus the API, CLI and MCP that go through it) from reading and writing the git repositories that store workspace configuration. Some requests that loaded or saved config returned an error. Config delivery was not affected: SDKs kept receiving config and flag evaluation in your applications worked normally throughout. https://status.quonfig.com/incident/1106886 Wed, 28 Oct 2026 14:32:00 -0000 https://status.quonfig.com/incident/1106886#0b1ab0bca103a679d5e63982282ee30d89f0bd0b82c6dcd2a3c6ddc8a40eaa32 Incident On October 28 from 09:53 to 10:32 EDT (13:53–14:32 UTC), our secondary config-delivery standby (secondary.quonfig.com / stream.secondary.quonfig.com) returned 503 errors. The host running the standby lost network connectivity, and our hosting provider's first two attempts to restart it failed. The third replacement instance started normally, warmed every workspace's configuration within seconds, and has been serving normally since. The primary delivery service (primary.quonfig.com) was healthy throughout, and SDKs fall back to it automatically, so we don't expect any customer impact. During this window the standby was not available as a failover target. No action is needed from customers. https://status.quonfig.com/incident/1099303 Thu, 22 Oct 2026 18:16:04 -0000 https://status.quonfig.com/incident/1099303#7e19e31c294a123a65f8ef2a8a232b2fc10993d203d6af1547d6e02b9d251441 Incident From about 18:09 to 18:12 UTC, some connections to the dashboard and telemetry ingestion failed or timed out at our hosting provider's (Fly.io) network edge in the US East and Frankfurt regions. Other regions were unaffected, and our services themselves stayed healthy. Everything recovered without intervention. SDKs retry on their own, and served configs were not affected. https://status.quonfig.com/incident/1092404 Fri, 16 Oct 2026 20:46:05 -0000 https://status.quonfig.com/incident/1092404#945263c32612abdf35045ef62b42157f0db8b0a5114181b587ffa1fe9d8bc947 Incident Resolved. The dashboard recovered at 20:46 UTC after about 10 minutes of unavailability, and has been stable since. Config delivery to SDKs was not interrupted. https://status.quonfig.com/incident/1092404 Fri, 16 Oct 2026 20:36:15 -0000 https://status.quonfig.com/incident/1092404#3cb373d64346a2e6f7e7a2792a3ca20cf8d9b2459ddd545f71d7eb885bed6de4 Incident Starting at 20:35 UTC, the Quonfig dashboard (app.quonfig.com) was unavailable or timing out. Our hosting provider, Fly.io, is rebooting hosts across all regions in phases (https://status.flyio.net). That has caused database failovers and machine restarts for our dashboard. We also saw a brief database connection blip at 18:28 UTC that lasted about 3 minutes. Config delivery to SDKs kept serving throughout. During the outage, API-key checks were answered from cached credentials, and some config requests saw higher latency. The dashboard is responding again as of 20:45 UTC. Fly.io reports that about half of its hosts have been rebooted so far, and the rest will take several more hours. More brief disruptions are possible until it finishes. We're monitoring and will post again when Fly.io's maintenance is complete. https://status.quonfig.com/incident/1078257 Wed, 30 Sep 2026 12:05:00 -0000 https://status.quonfig.com/incident/1078257#fc255a742adadea2efc03aaec56ee524fffa20de4bdfb55d13849e9051235322 Incident Between 07:24 and 07:26 UTC on September 30, our analytics database provider had a brief connectivity problem. During those ~2 minutes, some SDK usage telemetry sent to telemetry.quonfig.com could not be stored. The service recovered automatically, and ingestion has been normal since 07:26 UTC. Impact: For customers on older versions of SDK, a small amount of usage analytics from that window may be missing: flag evaluation counts, context data, and example contexts. Flag and config delivery was not affected. SDKs kept receiving and evaluating configuration normally, and your applications did not need to do anything. Next steps: Newer versions of the SDK have improved telemetry retry. Please update to the latest version of your SDKs. https://status.quonfig.com/incident/1077182 Tue, 29 Sep 2026 12:24:15 -0000 https://status.quonfig.com/incident/1077182#951837a28bb651a3fd3636c0d596a4a51d45cd018ad7fe61bb0336f7cd1c6036 Incident On September 29 from 07:29 to 07:54 EDT (11:29-11:54 UTC), our secondary config-delivery standby (secondary.quonfig.com / stream.secondary.quonfig.com) returned 503 errors. The standby's hosting provider stopped the instance it was running on, and it was restarted on a new host. The restart was normal except for a slow container image pull, which accounted for most of the 25-minute recovery. Once the new instance was up, it was fully warmed with every workspace's configuration and serving normally. The primary delivery service (primary.quonfig.com) was fully healthy throughout, and SDK clients kept getting configs from it without interruption. There was no customer impact. For those 25 minutes, the only effect was that the standby was not available as a failover target. No action is needed from customers. https://status.quonfig.com/incident/1073299 Thu, 24 Sep 2026 19:44:34 -0000 https://status.quonfig.com/incident/1073299#e24c3eb52c5ef10cbf0b348d531d78188259b348ecfd6310bda6b717e6bc0d76 Incident Between 8:07 PM and 9:12 PM Eastern on September 22 (00:07 to 01:12 UTC on September 23), our telemetry ingestion endpoint intermittently returned errors to SDKs. Config delivery, flag evaluation, and the dashboard were not affected. SDKs continued to serve flags normally throughout. What happened: our analytics database, ClickHouse Cloud, experienced a metadata-layer slowdown that made writes take 10 to 50 seconds instead of under a second. Every write still completed, but our ingestion service timed out at 30 seconds and reported an error to the SDK for data that had in fact been stored. SDKs treat that error as a failed send and discard the batch. The slow requests also caused our hosting platform to repeatedly start and stop extra ingestion machines, which produced the connection errors our monitoring recorded. Impact: roughly 5 to 13 percent of the flag evaluation counts and context data reported by SDKs during that hour were not recorded. You may see a small dip in evaluation charts for that window. No stored data was lost or corrupted, and no action is needed on your side. What we changed: on September 24 we deployed a fix to the ingestion service. It now waits up to 60 seconds for a slow write, retries a failed write up to three times, and tags every write so that a retry of a write that already landed is deduplicated rather than double counted. We also raised the concurrency limits so that slow writes no longer trigger machine churn, and added a dashboard that shows this failure mode directly. We have verified the change in production and believe this class of issue is resolved. We are separately looking at having SDKs hold on to a batch until it is acknowledged, which would close the remaining gap for longer outages. https://status.quonfig.com/incident/1073291 Thu, 24 Sep 2026 19:37:15 -0000 https://status.quonfig.com/incident/1073291#436c716c70d39374a2aff37e26606fc34c59359ce5fae5e3764b316125cc114b Incident On September 24 between 13:57 and 14:07 UTC, a small number of clients connecting to primary.quonfig.com from the Ashburn, Virginia area experienced TLS connection failures. The issue was isolated to a single edge server operated by our hosting provider. Clients routed to that server could not complete a TLS handshake. All other edge servers, including the two others in the same region, served traffic normally throughout. Impact was limited. Our config delivery service itself was healthy the entire time, with no errors or restarts. Quonfig SDKs that hit the affected server retried against our secondary delivery endpoint and received their configuration without interruption. We observed a handful of these automatic retries, all successful. No configuration data was stale, lost, or served incorrectly. The incident was detected by our external monitoring and resolved on its own once the affected edge server recovered. We continued to see intermittent connection errors from that one server through the afternoon, all absorbed by SDK retries, and it has been stable since approximately 19:00 UTC. We have raised the matter with our hosting provider. No action is needed from customers. https://status.quonfig.com/incident/1032577 Fri, 21 Aug 2026 17:13:00 -0000 https://status.quonfig.com/incident/1032577#5249e5e3f3be4ee20b231c25c0d7323fcdc47318530648c3970d542dab6a38eb Incident Between 17:00 and 17:13 UTC on 21 August this page showed quonfig.com, app.quonfig.com and telemetry ingestion as down. This was a failure in our external monitoring provider's probe network, not in Quonfig: every failed check came from a single probe cluster in Ashburn, VA, while probes from Europe and our own internal metrics showed normal traffic, zero errors and no dropped SDK connections throughout. No Quonfig service was affected. We are reviewing our monitoring configuration to reduce false alarms of this kind. https://status.quonfig.com/incident/1032576 Thu, 20 Aug 2026 07:35:00 -0000 https://status.quonfig.com/incident/1032576#3cfe0ea15b34834c8c6377553c292a93c501f6ecbe2fd984b37fe7203e82f5d9 Incident Between 07:11 and 07:35 UTC on 20 August, our hosting provider's managed Postgres service in the ORD region was partially down (Fly.io incident "MPG (v1) partially down in ORD": https://stspg.io/400fb1x28kty). app.quonfig.com could not reach its database for about 20 minutes and some dashboard requests returned errors. Config delivery to SDKs was not affected: the delivery API serves from an in-memory cache and kept authenticating previously-issued SDK keys throughout; we observed no failed config API requests. Service recovered when the provider restored the database cluster at 07:32 UTC. https://status.quonfig.com/incident/994212 Mon, 03 Aug 2026 15:17:00 -0000 https://status.quonfig.com/incident/994212#ccfaed32a21665a8f42bc850b9e6d3ebc02bb5343653ce363f5b9ce8106400c0 Incident All alerts resolved without intervention. Underlying metrics unchanged during the time period suggesting that this was an issue between our status page monitoring and the Fly edge. https://status.quonfig.com/incident/994212 Mon, 03 Aug 2026 14:58:00 -0000 https://status.quonfig.com/incident/994212#166cd5cf23e6fab07cd6f5d41e44d2bfe5ce3d9c18f66067d417abce9e4f2e00 Incident Numerous reported issues. Investigating. https://status.quonfig.com/incident/967448 Fri, 17 Jul 2026 19:43:00 -0000 https://status.quonfig.com/incident/967448#3d563896c1dc854c32867e1eded42f2bb6a880cc08985904867f9f7823911a26 Incident Between 10:09 and 10:13 UTC, a database connectivity issue at our infrastructure provider caused elevated latency (up to ~5 seconds) on some config API requests and brief errors for some dashboard users. No config API requests failed and all configuration data remained correct throughout. https://status.quonfig.com/incident/939795 Tue, 30 Jun 2026 21:39:00 -0000 https://status.quonfig.com/incident/939795#fda2b125cd9a6bbbbaf855f66d173f6310c95a23d660847dd8a40ce3f13009fc Incident Fixed issue with clickhouse. IP address issues. We lost incoming telemetry from 6/29 ~2pm until 6/30 5:30pm. https://status.quonfig.com/incident/939795 Tue, 30 Jun 2026 20:57:00 -0000 https://status.quonfig.com/incident/939795#26923445d7e60e0046a679bc90f147c8124f1930f38ce4527c21fd8b9d5090c9 Incident Investigating issues with our Clickhouse. Telemetry recording and evaluation charts have been affected. SDK performance and evaluations are unaffected.