Previous incidents

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.

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 ...

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 no...

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...

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 ser...

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 ...

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 c...

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.