rows filtered before indexing
703 buffers→4 buffers
Compared execution plans and captured indexed execution at 0.128 ms.
Based in Tbilisi · Open to global opportunities
TECHNICAL SUPPORT ENGINEER · L2 / APPLICATION / PRODUCTION
PORTFOLIO / 2026Production
Production
Support.
I'm Dwaragesh D—a Technical Support / Application Support engineer who reproduces issues, follows evidence across layers and documents clear, verified recoveries.
TABLE OF CONTENT
3.5years customer-facing technical experience
7Supabase incidents documented
502recovered to HTTP 200
2public support repositories
FLAGSHIP L2 PRODUCTION SUPPORT SIMULATION · 14 DOCUMENTED INCIDENTS
Project
NIGHTWATCH
JUL 2026 — PRESENTA production-style environment built to practise the complete support cycle—not isolated commands. Across 14 documented controlled incidents, I deployed the stack, introduced failures, correlated evidence across layers, restored service, validated recovery, and recorded RCA-ready notes.
DETECT→DIAGNOSE→RESTORE→PROVE
LIVE SYSTEM MAPALL LAYERS OBSERVED
ENTRYClientHTTP / JSON
→PROXYNginx500–504
→APPLICATIONFastAPIHealth / Logs
→DATAPostgreSQLLocks / Plans
PrometheusGrafanaAlertmanagerZabbixOpenSearchCloudWatch
Failures designed to cross layers.
- HTTP 500 / 502 / 503 / 504
- Backend and database dependency outages
- Kubernetes readiness failure and rollback
- SQL locks, connection spikes and recovery
- Controlled CI syntax failure
Recovery that can be inspected.
- Availability script with exit codes
- Alert failure-to-recovery lifecycle
- 14 incident records with timelines, recovery validation and root-cause reports
- Reusable runbooks and knowledge articles
- GitHub Actions validation pipeline
LinuxBashFastAPIPostgreSQLNginxDockerKubernetes / kindAWS EC2 / RDSGitHub Actions
PUBLIC REPOSITORYInspect NIGHTWATCH incidents, evidence and runbooksOpen project ↗INC-017 · CONTROLLED SEV-2 SIMULATION · NIGHTWATCH
HTTP 502:
upstream unavailable.
FINAL STATUSRESOLVED502 → 200 · recovery verified
This was a controlled outage in my public production-support lab. No customer or production system was affected. The investigation, evidence, recovery and follow-up controls are real and reproducible.
SEVERITYSEV-2Application route unavailable
AFFECTED PATH/appNginx reverse-proxy route
SYMPTOMHTTP 502Bad Gateway
DATA IMPACTNoneNo loss or corruption observed
INCIDENT TIMELINE · RELATIVE CLOCK
- Outage detected
A request through Nginx to
/appreturned HTTP 502 instead of the expected 200. - Proxy layer checked
Nginx was running and reachable, narrowing the failure to the upstream path rather than the public entry point.
- Error evidence found
The Nginx error log recorded
connect() failed (111: Connection refused) while connecting to upstream. - Listener verified
Linux port and process checks showed nothing listening on the configured backend port,
9999. - Root cause isolated
The Python backend process was unavailable; Nginx had a valid upstream target but no service accepting the connection.
- Service restored
The backend was restarted and the port listener was confirmed before traffic was tested again.
- Recovery verified
Direct backend and proxied
/appchecks both returned HTTP 200. Monitoring returned to a healthy state.
Requests through the application route failed.
Nginx remained available, but every request requiring the backend returned 502. From a user's perspective, the application was down. Static proxy availability alone would have produced a false healthy signal.
The error log identified the failing boundary.
I reproduced the 502, checked Nginx health, read the proxy error log, then validated the upstream with Linux port and process inspection. The decisive evidence was connection refusal plus the missing listener on port 9999.
The Python backend process was not running.
Nginx was correctly configured to forward requests to the backend, but no process was listening at the configured upstream address. The 502 was a proxy symptom, not an Nginx failure.
Restore, then prove every layer.
I restarted the backend, confirmed the listener on port 9999, requested the service directly, and finally tested the public Nginx route. Both paths returned HTTP 200; the 502 signal cleared.
INC-017 · DIAGNOSTIC EVIDENCE
CAPTURED DURING CONTROLLED OUTAGE$ curl -s -o /dev/null -w '%{http_code}\n' http://localhost/app
502
$ sudo tail -n 20 /var/log/nginx/error.log
connect() failed (111: Connection refused) while connecting to upstream
$ sudo ss -ltnp | grep ':9999'
[no output — no process listening on port 9999]
# backend restored; end-to-end route checked again
$ curl -s -o /dev/null -w '%{http_code}\n' http://localhost/app
200EVIDENCE CHAIN 502 response → upstream connection refused → missing listener → backend restored → 200 verified
WHAT CHANGED AFTER THE INCIDENT
Detection moved from manual observation to an actionable signal.
- Centralized evidence: streamed Nginx access and error logs to CloudWatch.
- Failure metric: created a log-based metric filter for HTTP 502 responses.
- Alert lifecycle: added an alarm and validated both failure and OK recovery states.
- Runbook sequence: documented proxy health, upstream logs, listener checks, direct validation and end-to-end verification.
OPERATIONAL LESSON
“A 502 tells you where the request failed—not why. The fastest path to root cause was correlating the proxy error with the missing upstream listener.”Inspect the supporting lab evidence ↗
SELECTED INCIDENT WORK
Support work, shown—not claimed.
These are hands-on lab incidents, kept separate from paid experience. Each one follows the same discipline: reproduce, isolate, restore, verify and document.
01AWS · NGINX · CLOUDWATCH
Recovered a failed backend behind Nginx
Traced HTTP 502 responses to an unavailable Python service on port 9999, restored the process, verified the listener and confirmed HTTP 200 end to end.
RESULT502 → 200
Full post-mortem 02POSTGRESQL · PERFORMANCE
Turned a sequential scan into an index scan
Used EXPLAIN ANALYZE to show 50,003 rows filtered before indexing, then added the right index and compared the execution plan and buffer usage.
RESULTBuffers 703 → 4
03KUBERNETES · OPERATIONS
Diagnosed a broken deployment rollout
Inspected pod state, events and logs, identified the faulty release and rolled the workload back to the last healthy revision.
RESULTService restored
04ZABBIX · OBSERVABILITY
Monitored an outage through failure and recovery
Configured host and HTTP monitoring, reproduced a service outage, investigated timeout events and verified the trigger cleared after recovery.
RESULTOutage → recovery
SUPABASE SUPPORT LAB · 7 INCIDENTS
Auth, data, storage and PostgreSQL—tested end to end.
JUL 2026 — PRESENTEach incident includes the failure, investigation, fix and verification. The lab separates anonymous, authenticated and database-level behavior instead of treating every API symptom as the same problem.
01
RLS visibility
Reproduced anonymous requests returning no rows and isolated the policy boundary.
Open incident evidence ↗02Auth & JWT
Diagnosed malformed login JSON, invalid credentials and validated an authenticated session.
Open incident evidence ↗03PostgreSQL performance
Compared sequential and indexed plans with measurable row and buffer evidence.
Open incident evidence ↗04PostgreSQL lock contention
Reproduced competing lock acquisition and verified recovery after the holding transaction completed.
Open incident evidence ↗05PostgREST request
Reproduced a bad Data API table path and traced the API error to the request target.
Open incident evidence ↗06Storage policy
Recovered a private-bucket upload by adding a bucket-scoped authenticated INSERT policy.
Open incident evidence ↗07External connectivity
Connected through the Session Pooler after diagnosing a password-authentication failure.
Open incident evidence ↗ANONYMOUS0 protected rowsRLS enforced
→AUTHENTICATED JWT4 support ticketsAccess verified
THE ENGINEERING FOUNDATION
Built systems first.
Now I support them.
My route into production support started at the hardware-software boundary: writing Python, integrating sensors, calibrating cameras and debugging systems where code, networks and physical devices all had to work together.
“That background trained me to follow evidence across layers—not stop at the first symptom.”
01 / CUSTOMER-FACING ENGINEERINGAUG 2020 — FEB 2024Technical Project
Technical Project
Engineer
Pantech ProEd · Coimbatore, India
Supported customers and project teams across Python, OpenCV, IoT and embedded systems: reproduced technical issues, troubleshot hardware-software failures, escalated complex cases and maintained clear technical documentation.
JUN 2024 — JAN 2026 Ran a business as sole operator before returning to technical work.
02 / OPERATIONSCURRENT FOCUS · HANDS-ON LABL2 / Application /
L2 / Application /
Production Support
Personal technical portfolio · Public evidence
Built realistic incidents across Linux, PostgreSQL, REST APIs, Nginx, monitoring, containers and AWS—then reproduced, isolated, restored, verified and documented each recovery.
WORKING TOOLKIT
Tools I've used hands-on.
Not a keyword cloud. Every item here connects to engineering work or a documented lab.
01Linux / Ubuntu
02AWS EC2 · RDS · CloudWatch
03PostgreSQL / SQL
04REST APIs · JSON · HTTP
05Nginx · FastAPI
06Docker · Kubernetes
07Prometheus · Grafana
08Zabbix · OpenSearch
09Jira · Confluence
10GitHub · GitHub Actions
11Python
PUBLIC EVIDENCE
Inspect the work.
LET'S SOLVE SOMETHING REAL