degraded9/25/2026, 7:52:21 PM — 8:22:58 PM50d ago
TaliLink stayed up for the whole 30-minute window: no failed API calls, no failed registrations, applications, or emails, and all three containers running normally on low load. Two things need attention: the backup email login is still broken, so if the primary sender (SES) fails, candidate emails have nowhere to fall back to; and at least one request took over 4 seconds to respond, which a candidate would have experienced as a page that hangs. Nothing is broken for users right now, but the email failover gap is a real risk that requires a human to replace an app password.
Findings
No email failover — backup SMTP credentials rejected
The open alert states Workspace SMTP rejected the backup password; SES is still sending and emailsFailed stayed at 0 across all 30 snapshots, so candidates are currently receiving stage-transition mail. But there is no second path if SES degrades — this is a single point of failure requiring a credential replacement.
Application response time spiked to 4.2s against a 308ms average
Application-path latency ranged 7.3ms to 4220.8ms (avg 307.95ms). The health-check path was unaffected (22–43ms, 100% reachable), so the slow response is likely a specific endpoint or query, not a platform-wide stall. With only min/avg/max available we cannot tell whether this was one outlier or a recurring tail.
Database write latency bursts to 50ms
Write latency averaged 7.61ms but peaked at 50.3ms, while read latency stayed near zero (avg 0.13ms) and CPU stayed under 5.6%. This is consistent with short write bursts or checkpoint activity rather than sustained pressure, and may be related to the latency spike above — but the data does not confirm a link.
Infrastructure is comfortably idle
Containers held 2.41% CPU and 25.51% memory on a steady 3 tasks; RDS held 9 connections, 4.44% CPU, and ~960MB freeable memory throughout. No resource constraint contributed to the latency spike.
Zero staff activity for the entire window
activeStaff was 0 in all 30 snapshots while activeTalents averaged 2.13 (peak 5). This is plausible off-hours behaviour, but it means no staff-facing path was exercised — staff-side breakage would not have shown up in this window.
Not covered by this report
- •Email delivery outcomes beyond the app's own failure counter: SES bounces, complaints, deferrals, and actual inbox delivery are not instrumented here. emailsFailed = 0 means the app recorded no send errors, not that candidates received their mail.
- •Pipeline stages past submission are not tracked. Only registrations and application submissions have counters; transitions into under review, assessment, interview, and decision — and any emails those trigger — are invisible in this data.
- •No latency percentiles or per-endpoint breakdown. Only min/avg/max are reported, so we cannot say whether the 4.2s response was a single outlier or a p95 problem, nor which route or query caused it.
- •topFailureReasons and collectionErrors are both empty, which may mean there were no failures or may mean failure reasons are not being captured. Error-level application logs and stack traces were not part of this dataset.
- •No ECS task restart/health-check history, no ALB target metrics, and no RDS IOPS/storage or slow-query log. Running tasks held at 3, but a task that crashed and was replaced between snapshots would not be distinguishable from steady state. Also, webLoad response time has only 25 of 30 samples — the 5 gaps likely align with zero-traffic snapshots, but that is an inference.
healthy9/25/2026, 7:21:11 PM — 7:51:48 PM50d ago
TaliLink was fully available for the whole 30-minute window: no failed API health checks, no server errors on the API or website, and no failed registrations, applications, or emails were recorded. Infrastructure is running cold (CPU under 4%, three tasks steady, database relaxed). The one thing needing human action is unrelated to current performance: the backup email login is broken, so if the primary email provider (SES) stops working, stage-transition emails to candidates would have no fallback. Nothing here was fixed or changed by this report.
Findings
No email failover — backup SMTP credentials rejected
Open alert states Workspace SMTP rejected the backup app password; SES is still sending, so no candidate-facing impact is visible in this window (emailsFailed was 0 in every snapshot). This is a single-point-of-failure risk for transactional mail until the app password is replaced.
Availability and error rates clean
0 unreachable cycles, 100% uptime, health-check latency 23–56 ms (avg 32 ms). HTTP 5xx stayed at 0 per minute on both API and web; 4xx averaged about 1.2/min on the API (peak 6/min) and about 0.7/min on web (peak 8/min), consistent with normal auth/validation noise. Period totals are not measurable from these sampled rates.
API latency tail reaches ~2.1 s despite trivial load
Application response time averaged 331 ms but peaked at 2,129 ms while request rate was only ~29/min (peak 82/min) and container CPU stayed under 3.6%. The spike is therefore not resource contention; it is consistent with a slow individual query, a cold start, or an outbound call (e.g. email send) on the request path — but only min/avg/max are exposed, so it cannot be attributed to an endpoint.
Database write latency spikes to 35 ms
Write latency averaged 7.2 ms but hit 35.3 ms, against read latency near 0 and DB CPU under 6.6%. Likely correlated with the API latency tail; worth checking whether the same minute is involved, though at this load it is not currently harmful.
Zero staff activity for the entire window
activeStaff was 0 in all 30 snapshots while activeTalents averaged 4.7 (peak 9). This is plausible for off-hours, but a flat zero is indistinguishable from a broken counter — it should not be read as evidence that staff-facing flows work.
Not covered by this report
- •Email delivery is only observed as 'emailsFailed = 0'. There is no metric for emails actually sent, accepted by SES, bounced, or delayed — so a silent stall (nothing queued, nothing sent) would look identical to a healthy zero.
- •Only min/avg/max latency is available; there are no p95/p99 or per-endpoint/per-route breakdowns, so the 2.1 s API peak cannot be localised and sustained slowness on one endpoint could be masked by a fast average.
- •All error data is application-reported. No ALB-level metrics (target 5xx, rejected/spillover connections, target group health, surge queue) are present, so failures occurring before traffic reaches the API would not appear here.
- •The pipeline is only instrumented at registration and application submission. Progression through under review, assessment, interview and decision — and any transitions stuck or failing at those stages — is not observed.
- •No background job/queue depth, worker health, or retry-backlog metric is present, and DB connections were a flat 9 with no known pool maximum — so queue buildup or pool saturation headroom cannot be assessed. topFailureReasons was empty, which means no reasons were reported, not that failure detail was checked and found clean.
healthy9/25/2026, 6:50:08 PM — 7:20:45 PM50d ago
TaliLink served every request it was asked to serve during this ~30 minute window: no API outages, no server errors (5xx), and candidate registrations and job applications all succeeded with zero recorded failures. Infrastructure is barely working — containers at ~3% CPU, database at ~4% CPU. The one thing needing human action is the open alert: the backup email login is rejected, so email is currently running on a single provider (SES) with no fallback if it fails. Note also that no staff/recruiter accounts were active in this window, so the recruiter-facing side of the product was effectively untested by real traffic.
Findings
No availability or server-error problems observed
API was reachable in all 30 snapshots (100% uptime), and both API and web recorded 0 HTTP 5xx per minute throughout. Health-check response time stayed tight at 21–38 ms.
Email failover is broken (open alert)
Workspace SMTP is rejecting the backup app password; SES is still delivering, so no candidate-facing impact is visible in this data, but there is no second path if SES degrades. Replacing the app password is the action item.
Application-request latency spikes well above its average
API request latency averaged 272 ms but peaked at 1,769.9 ms — roughly 6.5x the mean — while CPU, memory and DB connections stayed flat. The cause is not identifiable from this data (no per-route or percentile breakdown); consistent with occasional slow queries or cold paths rather than saturation.
Database write latency is spiky though low on average
Write latency averaged 6.8 ms with a 35.3 ms peak, against near-zero read latency (avg 0.22 ms). Freeable memory (~958 MB) and connections (steady at 9) show no pressure; likely burst-related and worth watching only if it correlates with the API latency peaks.
Low 4xx rate, but source unknown
API returned about 2 client errors per minute, peaking at about 11 per minute; web about 0.5 per minute peaking at 4. The period total is not measurable from this sampled data, and there is no breakdown by route or status code to tell routine 401/404 noise from a broken client flow.
Not covered by this report
- •Email delivery outcomes are not observed: only 'emailsFailed' (0) is reported. Bounces, SES throttling, deferrals, spam placement, and whether stage-transition emails actually reached candidates are not instrumented — this is not evidence email is working end to end.
- •Recruiter/staff-side functionality was exercised by nobody: activeStaff was 0 for all 30 snapshots. Any breakage in staff login, pipeline review, or stage-advance actions would not show up in this window.
- •Pipeline stage transitions beyond registration and application submission (under review, assessment, interview, decision) have no counters here, so candidates stuck or silently failing mid-pipeline would be invisible.
- •Only min/avg/max are available — no p95/p99, no per-endpoint or per-status breakdown. The 1,769.9 ms peak cannot be attributed to a route, and it is unknown how many users experienced multi-second responses.
- •No background-job, queue-depth, or retry metrics, and no ALB/target-level or client-side (browser error, JS failure) telemetry. Async work backing up, or a frontend that renders broken while the server returns 200, would not appear in this report.
degraded9/25/2026, 6:18:57 PM — 6:49:35 PM50d ago
TaliLink was up and serving users for the whole window: no failed registrations, no failed applications, no server errors, and the API answered every health check (100% uptime, 20-67ms). The one real problem is not visible to candidates — the backup email login is rejected, so transactional email currently runs on SES with no fallback; if SES has a problem, stage-transition emails stop with nothing to catch them. Someone needs to replace the backup app password. Everything else looks like a lightly loaded, healthy system, with one latency spike worth a look but no user-facing failures recorded.
Findings
Transactional email has no failover path
Open alert: Workspace SMTP rejected the backup password, so SES is the only sending route. emailsFailed was 0 across all 30 snapshots, meaning nothing has broken yet — but this is a single point of failure for candidate stage-transition email until the app password is replaced.
API request latency spikes far above its average
Application-level response time averaged 379ms but reached 2,387ms at least once, while container CPU stayed at ~2.7% and memory ~24.7% with 3 tasks steady. Saturation is not the cause; this is consistent with a specific slow query or endpoint, but the data has no per-route breakdown to confirm.
Database write latency is spiky relative to a near-idle instance
Write latency averaged 7.38ms and peaked at 36.3ms while RDS CPU stayed at 3.89-5.95% and read latency was ~0.17ms. Load is not driving it; likely EBS burst/IO behaviour or a heavy write path, and it lines up plausibly with the API latency spike though the data cannot prove the link.
No server errors; light and variable traffic
API 5xx and web 5xx were 0 per minute in every snapshot. API traffic averaged about 34 requests/min peaking at 75, with about 1.6 4xx/min peaking at 5 (plausibly ordinary auth/validation rejections). Totals for these are not measurable from this sampled data.
Staff activity reported as exactly zero for the entire window
activeStaff was 0 in all 30 snapshots while activeTalents ranged 2-9. This may simply mean no recruiter was online, but a constant zero is also what a broken or never-firing signal looks like — recruiter-side workflows are effectively unverified here.
Not covered by this report
- •Email delivery outcomes beyond the app's own failure counter: SES bounce, complaint, deferral and actual inbox delivery rates are not instrumented, so 'emailsFailed: 0' means the app saw no send errors, not that candidates received mail.
- •Latency percentiles: only min/avg/max are collected, so p95/p99 are unknown — the 2.4s peak could be one request or a recurring tail affecting a meaningful share of users, and this data cannot distinguish them.
- •No per-endpoint, per-route or per-query attribution. The slow API request and the 36ms write cannot be localised to a stage transition, search, or application submission from this data.
- •Pipeline progression is unobserved: there are counters for registrations and application submissions, but nothing for stage transitions (under review → assessment → interview → decision), so candidates silently stuck mid-pipeline would not appear anywhere in this report.
- •Infrastructure edges are not covered: no ALB target 5xx/rejected-connection counts, no RDS IOPS/burst-balance or slow-query log, no background job/queue depth, and no browser-side Next.js errors. DB connections sat at exactly 9 in every snapshot, which may be a pool floor rather than a measure of real concurrency.
healthy9/25/2026, 5:47:52 PM — 6:18:30 PM50d ago
TaliLink was up for the whole 30-minute window with no server errors and plenty of spare capacity — candidates could register and apply normally. The one thing needing human action is the email alert: transactional email is still going out via SES, but the backup email login is rejected, so there is no fallback if SES fails. Someone should replace that app password. Nothing in this report was broken enough to page anyone, but it also cannot see whether emails actually reached candidates' inboxes.
Findings
No email failover — backup SMTP credentials rejected
Open warning alert: Workspace SMTP rejected the backup password, so SES is a single point of failure for stage-transition email. Workflow counters show zero email failures in this window, which is consistent with SES sending normally, but that is exactly why the missing failover is easy to forget.
Availability and error rates clean
Zero cycles with the API unreachable (100% uptime across 30 snapshots), and HTTP 5xx held at 0 per minute on both API and web for every sample. 4xx ran low — about 1.8/min on the API (peak 8/min) and about 0.7/min on the web tier (peak 7/min); these rates cannot be converted to a period total from this data.
API latency tail reaches ~1.15s while the median path stays fast
Application response time averaged 280ms but peaked at 1154.7ms, against a health-probe time of 21–52ms and near-idle infrastructure. Likely a small number of slow endpoints or cold query paths rather than saturation, but only min/avg/max are exposed so the tail cannot be attributed to a route.
Infrastructure is far from any limit
ECS held a steady 3 tasks at 2.2–4.3% CPU and ~24% memory; RDS sat at 4–5.6% CPU, a flat 9 connections, and ~950MB freeable memory. Headroom is ample; nothing here explains the latency tail.
DB write latency spikes to 34.8ms against a 0.17ms read path
Write latency averaged 7.09ms with a 34.8ms peak while reads were essentially free — consistent with periodic flush/commit bursts on a low-traffic instance. Worth watching only if it correlates with the slow API samples; this data cannot establish that correlation.
Not covered by this report
- •Email delivery outcomes are not observed. The 'emailsFailed: 0' counter reflects send attempts the app knows failed — it says nothing about SES bounces, spam placement, deferrals, or queue depth, and it does not verify the broken backup SMTP path.
- •activeStaff read 0 in every snapshot. This report cannot distinguish 'no recruiters were logged in' from 'staff-session instrumentation is not reporting', so staff-facing breakage would look identical to an idle window.
- •Pipeline stages beyond submission are not instrumented. There are counters for registrations and applications submitted, but none for under review, assessment, interview, or decision transitions — candidates could be stuck mid-pipeline with no signal here.
- •Only min/avg/max are available for latency and load — no percentiles, no per-endpoint or per-route breakdown, and no traces or logs. The 1154.7ms peak cannot be attributed to a specific endpoint, tenant, or query.
- •No ALB-level or container-lifecycle metrics: target health, LB-side 5xx and connection resets, ECS task restarts, OOM kills, and deploy events are all unobserved. Running tasks held at 3, but a task that crashed and was replaced between snapshots would not be visible.
- •All per-minute rates here are overlapping samples, so no period totals — total requests, total 4xx, total registrations — are measurable from this data.
healthy9/25/2026, 5:16:45 PM — 5:47:22 PM50d ago
TaliLink stayed up for the whole 30-minute window: no failed API calls (zero 5xx), no failed registrations, applications or emails, and plenty of spare CPU, memory and database capacity. Two things need a human: the backup email login is still broken, so if the primary sender (SES) fails there is no fallback, and some API requests are taking up to about 2 seconds even though the servers are nearly idle. Neither is breaking anything for candidates right now.
Findings
Email failover is down (open alert)
Workspace SMTP is rejecting the backup app password; SES is still delivering and emailsFailed was 0 across all 30 snapshots, so this is a loss of redundancy rather than an outage. Replacing the app password removes a single point of failure on stage-transition email.
API tail latency out of proportion to load
Application response time averaged 447ms with a peak of 2032.6ms, while the external health probe stayed at 22-159ms and containers sat at ~2.9% CPU on 3 tasks. Consistent with a small number of slow endpoints or queries rather than saturation; a per-route breakdown is needed to confirm.
Database write latency spikes
Write latency averaged 7.85ms but peaked at 38.1ms, against read latency averaging 0.47ms, with DB CPU under 6.5% and a flat 9 connections. Likely EBS burst/flush behaviour or write-heavy bursts; worth correlating with the API latency peaks.
Client-side errors present but unexplained
The API returned roughly 2.8 4xx responses per minute, peaking at about 9 per minute; the web tier averaged about 1 per minute, peaking at about 11. No failure reasons were captured, so whether these are ordinary auth/validation noise or a broken client path is unknown. A period total is not measurable from this sampled data.
Only early-funnel activity was exercised
Registrations succeeded steadily (about 9-11 per snapshot) but applications submitted averaged 0.13 (max 2) and active staff was 0 for all 30 snapshots. The later pipeline stages (review, assessment, interview, decision) were effectively untested in this window, so their health is unproven, not proven good.
Not covered by this report
- •Email delivery outcomes are not instrumented beyond a failure counter: bounces, deferrals, SES throttling, queue depth and actual candidate inbox delivery were not observable. emailsFailed = 0 means no locally-recorded failures, not confirmed delivery.
- •No per-endpoint or per-query latency breakdown, so the 2-second peak cannot be attributed to a specific route, N+1 query, or external call; no slow-query log or APM trace data is present here.
- •No failure-reason data at all (topFailureReasons was empty), so the nature of the 4xx responses — auth failures, validation errors, bots, or a broken frontend call — is unknown.
- •No ALB-level metrics (target health, connection errors, surge/rejected connections) and no per-task metrics; the container figures are aggregates, so one unhealthy task among the three could be hidden in the averages.
- •Staff/recruiter-facing paths and stage-transition workflows produced no traffic (activeStaff = 0), and there are no metrics for background jobs, retries, or queue backlogs — those subsystems are unobserved, not verified healthy.
degraded9/25/2026, 4:45:36 PM — 5:16:14 PM50d ago
TaliLink stayed up for the whole 30-minute window: no failed requests, no server errors, and candidate registrations kept succeeding. Two things need a human: the backup email login is still broken (only the primary sender works, so there is no fallback if it fails), and some application requests took as long as 4.3 seconds even though the servers were almost idle. Nothing is broken for users right now, but the system has no email safety net and one unexplained slow path.
Findings
No email failover — backup SMTP login rejected
The open alert reports Workspace SMTP rejecting the backup app password; SES is still sending, so this is a redundancy gap, not an outage. Replacing the app password is the action; until then a single SES problem means no transactional email at all.
Latency tail up to 4.3s with no resource pressure
Application request time averaged 527ms but peaked at 4,283ms, while ECS CPU stayed at ~2.7%, memory ~24.8%, and DB CPU ~4.5%. Consistent with a slow individual query, an external call, or a cold path rather than saturation — but with only min/avg/max (no percentiles or per-route breakdown) the cause is not identifiable from this data.
Zero applications submitted across the entire window
applicationsSubmitted was 0 in all 30 snapshots while registrations kept succeeding and 1–11 talents were active. This could simply be low traffic, but it means the apply path was never exercised and its health is effectively unverified; applicationsFailed being 0 proves nothing here.
Client errors present, server errors absent
API 4xx ran at about 2.6 per minute, peaking at 12 per minute; 5xx stayed at 0 per minute throughout. These are sampled overlapping rates, so no period total can be stated. With no failure-reason breakdown (topFailureReasons is empty), whether these are auth retries, validation rejections, or 404s is unknown.
Infrastructure steady and well under capacity
3 ECS tasks running for all 30 snapshots, DB connections pinned at exactly 9, freeable memory flat at ~960MB, read latency ~0.07ms. Write latency averaged 7.2ms with a 33.8ms peak — worth a glance if it recurs, but currently benign.
Not covered by this report
- •Email delivery is not actually observed: emailsFailed is 0, but there is no counter for emails attempted or delivered, and no SES bounce/complaint/deferral data. Zero failures here does not confirm candidates received anything.
- •Pipeline stage transitions (submitted → under review → assessment → interview → decision) are not instrumented. With activeStaff at 0 for all 30 snapshots, no transition-triggered path — including its emails — was exercised or verified.
- •The backup SMTP path has no health signal beyond the alert itself; there is no probe confirming whether SES is genuinely healthy or merely not yet failing, so the blast radius of losing it is untested.
- •Latency is reported only as min/avg/max with no p95/p99 and no per-endpoint or per-query breakdown, so the 4.3s peak cannot be attributed to a route, a database query, or an external dependency.
- •No ALB target-health, ECS task restart/OOM-kill, RDS storage/IOPS, or background job/queue-depth metrics are present. A task could have cycled or a queue backed up within this window without appearing anywhere in this report.
degraded9/25/2026, 4:14:32 PM — 4:45:10 PM50d ago
TaliLink stayed up and fast for the whole 30-minute window — no outages, no server errors, and plenty of spare capacity on both the app and the database. The one real problem is email: a small but steady trickle of email sends is failing, and the backup email login is rejected, so if the primary sender (SES) stops working there is nothing to fall back on. Action for a human: get the Workspace app password replaced so failover exists, and have someone check whether any candidates missed a stage-transition email. Also note no staff users were active at all in this window, so the reviewer-side of the pipeline was effectively untested here.
Findings
Email sends are failing continuously
Failed emails ran at roughly 0.6 per snapshot, reaching 1 in most snapshots — small in volume but never dropping to zero across all 30 snapshots. No failure reasons were captured (topFailureReasons is empty), so the cause is not visible in this data.
No email failover path (open alert)
Workspace SMTP is rejecting the backup app password. SES is still delivering, but the redundancy is gone; a SES-side problem would become a full transactional-email outage with no automatic cover.
API latency spikes far above baseline
Application request handling averaged 289ms but peaked at 2,270ms — roughly 8x the mean. Only min/avg/max is available, so how often slow requests occur and which endpoints they hit cannot be determined from this data.
Database write latency bursts while otherwise idle
RDS write latency averaged 6.3ms but peaked at 38.2ms, with CPU at ~4% and a flat 9 connections. Consistent with brief IO bursts rather than load pressure; likely correlated with the API latency peaks, though nothing here confirms that link.
Infrastructure comfortably under-utilised; zero staff activity
3 ECS tasks steady at ~2.7% CPU and ~24.6% memory, DB at ~4.4% CPU — no capacity concern. Active staff was 0 for every snapshot, so recruiter-driven stage transitions (review, assessment, interview, decision) generated no measured traffic in this window.
Not covered by this report
- •Email delivery outcomes are not instrumented — only send failures are counted. Bounces, SES throttling, spam placement, and whether retried messages eventually arrived are all unknown; a low failure count is not evidence candidates received their emails.
- •No failure reasons were recorded for the failing emails, so the failures cannot be attributed to SMTP auth, SES limits, bad addresses, or app-side errors from this data.
- •Latency is reported only as min/avg/max with no percentiles and no per-endpoint or per-route breakdown, so the 2,270ms peak cannot be located or sized. The number of slow requests is not measurable from this data.
- •All rate metrics (requests, 4xx, 5xx) are overlapping samples, so period totals are not derivable — the 4xx rate of ~2.3/min peaking at 16/min cannot be converted into a count of affected users or requests.
- •Nothing here covers the staff/recruiter side of the pipeline: with activeStaff at 0 throughout, stage-transition correctness, queue/worker backlogs, and job-processing health were not exercised or observed. Also absent: ALB target health, container restarts/OOM kills, RDS IOPS and storage, and frontend client-side errors.
degraded9/25/2026, 3:43:25 PM — 4:14:02 PM50d ago
TaliLink stayed up for the whole 30-minute window — no outages, no server errors, and plenty of spare capacity on the API containers and database. Two things need a human: at least one candidate email is failing because the recipient is on the SES suppression list (that person is not receiving stage-transition mail), and the backup email account's password has been rejected, so if SES stops working there is no fallback. Separately, some API requests are taking over a second while the average is a third of a second, which is worth a look but is not breaking anything yet. No staff accounts were seen active at all during the window while candidates kept registering and applying.
Findings
Email failures persist for the whole window; no failover available
Every one of the 30 snapshots reported 1 failed delivery, reason 'Recipient is on the SES suppression list'. Whether this is the same recurring failure or a new one each snapshot is not distinguishable from this data, so the total is not measurable here. Compounding this, the backup Workspace SMTP account is rejecting its app password, so SES currently has no failover path.
API latency tail is ~40x the median-ish average
Application request latency averaged 318 ms but peaked at 1385.6 ms, while the health-check probe stayed at 22–89 ms. Something in the request path spikes intermittently; with only min/avg/max available, how often and on which endpoints is unknown.
Database write latency is spiky against a nearly idle database
Write latency averaged 7.95 ms with a 37.9 ms peak, while DB CPU stayed under 7%, connections were pinned at 9, and freeable memory was flat around 960 MB. This is consistent with burst-credit or EBS I/O behaviour rather than load, and is a plausible contributor to the API latency spikes — that link is inferred, not shown.
Zero staff activity while candidate volume continued
activeStaff was 0 across all 30 snapshots while activeTalents averaged 6.5 and registrations ran 11–20 per snapshot. This may simply be off-hours, but it means nobody was advancing candidates through review/assessment/interview during this window.
Infrastructure and error rates are clean
100% uptime, 0 cycles unreachable, HTTP 5xx at 0/min on both API and web, 4xx at about 2/min on the API (peak 13/min) and about 0.8/min on the web (peak 7/min). Three ECS tasks stayed running at ~2.7% CPU and ~24% memory — no capacity pressure of any kind.
Not covered by this report
- •Email success/queue volume is not instrumented — only failures are counted. We cannot confirm that the other transactional emails actually reached candidates, nor whether a backlog is building behind SES.
- •No per-endpoint or per-route latency breakdown and no p95/p99 — only min/avg/max. The 1385 ms peak cannot be attributed to a specific operation, and we cannot tell whether slow requests are rare or affect a meaningful share of traffic.
- •No pipeline-stage transition metrics. Registrations and application submissions are counted, but movement through under review / assessment / interview / decision is invisible, so a stalled pipeline would look identical to a healthy one here.
- •All HTTP counts appear to be app-reported; there are no ALB-level metrics (target 5xx, rejected or reset connections, target health flaps). Errors that never reached the NestJS app would not appear in this report.
- •topFailureReasons and collectionErrors are empty lists, not confirmed zeros — absence of recorded failure reasons is not evidence that nothing else failed. There is also no visibility into background jobs/workers, ECS task restarts, or application exception logs.
degraded9/25/2026, 3:11:57 PM — 3:42:51 PM50d ago
TaliLink stayed up for the whole 31-minute window: no failed requests (zero 5xx), no failed registrations or applications, and the servers and database were barely working (CPU under 5%). Two things need a human: at least one candidate email was rejected because the recipient is on the email provider's suppression list, and the backup email account's password is rejected, so if the main email provider fails there is no fallback. Separately, some API requests took over 2 seconds even though the system was nearly idle, which is worth a look before traffic grows. Nothing here has been changed or fixed — this is observation only.
Findings
No email failover available
An open alert reports Workspace SMTP rejecting the backup app password; SES is still delivering, so there is no current outage, but the platform has a single point of failure for all stage-transition email. Replacing the app password is a manual, low-risk action.
Candidate email delivery failure (SES suppression list)
The failed-email counter sat at 0-1 per snapshot (avg 0.27) and the alert attributes one failure to the recipient being on the SES suppression list. That is a per-recipient deliverability issue, not an infrastructure fault; the affected candidate likely received no stage notification. An exact period total is not derivable from overlapping snapshots.
API latency tail far above the median, on an idle system
Application response time averaged 372 ms but peaked at 2,175.9 ms while container CPU stayed under 4.6% and DB CPU under 6.7%. This is consistent with a few slow endpoints or queries (DB write latency also spiked to 37.1 ms against a 6.3 ms average) rather than saturation — but with only min/avg/max we cannot see how often the slow path is hit.
Client errors present, causes unknown
API 4xx ran at roughly 3 per minute, peaking at about 14 per minute; the web tier around 2 per minute, peaking at about 14. No failure-reason breakdown was collected, so we cannot tell validation errors from auth failures or broken links. No 5xx were observed on either tier.
Zero staff activity; workflow counters look synthetic
Active staff was 0 in every snapshot while registrations reported 16-20 per snapshot against only ~9 active talents and ~2.5 applications — a pattern consistent with seeded/test traffic or a cumulative counter rather than real signups. Staff-driven pipeline transitions were therefore not exercised, so their health is untested, not proven good.
Not covered by this report
- •No latency percentiles or per-endpoint breakdown — only min/avg/max. We cannot say whether the 2.2 s peak affected one request or many, or which route (registration, apply, stage change) was slow.
- •No email success/bounce/complaint volumes or queue depth — only a failure count. The health of the overall SES sending path, reputation, and whether retries occurred is unknown.
- •No pipeline-stage instrumentation: time-in-stage, stuck candidates, and failed or missing stage transitions are not measured, so a silently stalled pipeline would look identical to a healthy one here.
- •No ECS task restart, OOM-kill, or deployment-event data. Running tasks read a steady 3, but that does not rule out a task having crashed and been replaced between snapshots.
- •No logs, traces, DB slow-query/lock metrics, or frontend client-side error reporting — so the cause of the latency tail and the 4xx rate cannot be identified from this data, and staff-side flows (zero active staff all window) have no evidence either way.
healthy9/25/2026, 2:40:51 PM — 3:11:29 PM50d ago
TaliLink was up for the whole 30-minute window with no failed registrations, applications, or emails, and no server errors on either the API or the website. Candidate-facing performance was good; a few brief slow moments occurred but nothing users would likely notice as an outage. One thing does need human action: the backup email login is broken, so if the main email provider (SES) fails, stage-transition emails would stop with no fallback. Note that no staff were active during this window, so recruiter-side workflows were not exercised or observed.
Findings
Email failover is broken (open alert)
Workspace SMTP rejected the backup password; SES is still sending and application-level email failures were 0 across all 30 snapshots, so there is no current impact. However, the platform is single-pathed for transactional email until the app password is replaced — a SES issue would mean silent loss of stage-transition notifications.
Intermittent latency spikes against a low baseline
API health-probe response averaged 39ms but peaked at 323ms; application request latency averaged about 118ms with a peak of 870ms. With CPU at ~2.8% and memory ~23.7% on 3 steady tasks, this is not resource exhaustion — likely a slow query, an external call, or a cold path, but the data cannot attribute it.
Database write latency spike to 105ms
RDS write latency averaged 9.6ms but one sample reached 105ms, while read latency stayed at ~0.26ms, CPU under 6.2%, and connections pinned at 9. Consistent with a burst of writes or storage-level jitter rather than saturation; worth correlating with the 870ms application latency peak.
Steady 4xx rate with a burst
API 4xx ran at about 3.9 per minute on average, peaking at about 16 per minute; the web tier averaged about 0.9 per minute, peaking at about 7. These are sampled rates with overlapping windows, so a period total is not measurable from this data. No status-code or endpoint breakdown is available, so validation errors cannot be separated from auth failures or probing traffic.
Candidate flow healthy; staff side untested
Registrations (avg ~11.6 per snapshot, peak 16) and application submissions (avg ~3.2, peak 4) succeeded with zero failures, and 3–14 active talents were present throughout. Active staff was 0 for all 30 snapshots, so reviewer/interviewer paths and later pipeline stages produced no traffic and this report says nothing about their health.
Not covered by this report
- •Email delivery outcomes are not observed — only application-side send failures (0) are counted. SES bounces, deferrals, spam placement, and whether candidates actually received stage-transition mail are unknown, which matters more than usual while failover is down.
- •Pipeline stage transitions beyond 'application submitted' are not instrumented. Movement through under review, assessment, interview, and decision — and any stall or error in those transitions — is invisible here.
- •No ALB-level metrics (target 5xx vs LB 5xx, connection errors, rejected connections, target health flaps). Requests that failed before reaching the API would not appear in the application 5xx counts, which read 0.
- •No per-endpoint or per-status-code breakdown, and no error/exception logs or traces. The 4xx rate and the 870ms latency peak cannot be attributed to a specific route, tenant, or query.
- •No visibility into background work: job/queue depth, retry backlogs, or scheduled task outcomes are not reported, so a silently stuck worker would still show as a clean run. Deploys, task restarts, and RDS failover events are also not covered.
healthy9/25/2026, 2:09:39 PM — 2:40:16 PM50d ago
TaliLink stayed up for the whole 30-minute window: no failed API checks, no server errors on either the API or the website, and candidate sign-ups and job applications all completed with zero failures. Two things deserve attention rather than panic: a few individual requests were unusually slow (one took about 2.5 seconds against a typical quarter-second), and the backup email account still cannot log in, so if the main email provider stops working there is nothing to take over. No staff members were logged in during this window, so this report says nothing about whether the recruiter-facing side of the product is working.
Findings
No email failover — backup SMTP login rejected
Open alert: Workspace SMTP rejected the backup app password. SES is still delivering (emailsFailed stayed at 0 across all 30 snapshots), but transactional stage-transition email is currently single-provider with no fallback. Replacing the app password is the fix; nothing here has been changed.
Occasional multi-second API responses under trivial load
Application response time averaged 289 ms but peaked at 2,525 ms, while request volume averaged about 27 requests per minute (peak 70) and container CPU never exceeded 3.4%. This is not resource saturation; it is consistent with a slow query, a cold path, or an external call. Only min/avg/max are available, so we cannot tell whether this was one request or a recurring tail.
Database write latency spiked to 37.5 ms
Write latency ranged 0.2–37.5 ms (avg 6.68 ms) against read latency of essentially 0 ms and DB CPU under 6%. The spike plausibly coincides with the slow API responses, but these are aggregates without timestamps so the correlation cannot be confirmed from this data.
Zero staff activity for the entire window
activeStaff was 0 in all 30 snapshots while 1–5 candidates were active. Recruiter-facing endpoints, pipeline stage transitions, and the emails they trigger were therefore largely unexercised — the absence of errors on those paths is untested, not proven.
Low-level 4xx traffic with no attribution
The API returned about 1.5 client errors per minute, peaking at 8 per minute; the web tier about 0.9 per minute, peaking at 7. The period total is not measurable from this sampled data. topFailureReasons was empty, so we cannot distinguish bad logins, validation rejects, 404s, or bot scanning.
Not covered by this report
- •No latency percentiles or per-endpoint breakdown — only min/avg/max are collected, so the 2.5 s peak cannot be localised to a route or confirmed as a recurring p99 rather than a one-off.
- •No email delivery telemetry beyond a failure counter: SES send volume, bounces, complaints, and delivery latency are not instrumented, so 'emailsFailed: 0' means 'nothing reported a failure', not 'candidates received their mail'.
- •Pipeline stage transitions (under review, assessment, interview, decision) are not instrumented; only registrations and application submissions are counted, so a stuck or silently failing stage move would be invisible here.
- •No infrastructure-level detail beyond aggregate container/RDS stats: no ALB target health or 5xx from the load balancer itself, no per-task metrics, no background job or queue depth, and no deploy/restart events to correlate against the latency spike.
- •Frontend response time has samples in only 24 of 30 snapshots (web traffic hit 0 rpm at times), so roughly a fifth of the window has no web latency observation at all — that is a gap, not a period of good performance.
healthy9/25/2026, 1:38:29 PM — 2:09:08 PM50d ago
TaliLink was up and serving traffic for the whole 30-minute window: no failed requests, no failed registrations, applications or emails, and plenty of spare capacity on both the servers and the database. Two things deserve attention rather than panic: the backup email login is still broken, so if the primary email provider (SES) stops working there is no fallback and candidates would silently stop receiving stage-transition emails; and no staff/recruiter activity was recorded at all in this window, meaning the recruiter side of the pipeline was never exercised and this report cannot vouch for it. Nothing here needs an emergency response, but the email failover should be fixed before it is needed.
Findings
Full availability, zero server errors
API was reachable in all 30 check cycles (100% uptime, health probe 21-58ms). HTTP 5xx was 0 per minute on both API and web for every sample; client errors stayed low at about 1.4/min on the API (peak 9/min) and 0.8/min on web (peak 7/min) against roughly 39 API requests/min. Totals are not measurable from this sampled data.
Email failover is unavailable (open alert)
Workspace SMTP rejected the backup app password, so SES is the sole sending path with no redundancy. Measured emailsFailed was 0/min throughout, meaning the primary path is currently working — but this metric only counts send failures the app observes, so it is not evidence that failover risk is contained.
Latency tail well above the average
Application response time averaged 159ms but peaked at 989.9ms; the web tier stayed flat (avg 8.4ms, max 27ms), so the slowness is API/DB-side, not frontend. With CPU at ~2.7% and memory ~24% on 3 steady tasks, this is likely query- or I/O-bound rather than resource exhaustion.
Database write latency is spiky
Write latency averaged 7.8ms with a 37.9ms peak, while read latency stayed near zero (avg 0.3ms) and DB CPU under 7% with a flat 9 connections. The write spikes are consistent with the API latency peaks, but these are period aggregates, so a snapshot-level correlation is inferred, not demonstrated.
No staff activity recorded for the entire window
activeStaff was 0 in all 30 snapshots while candidate activity continued (avg ~5.9 active talents, ~5.2 registrations and ~3.6 applications per snapshot). This is plausible for off-hours, but it means recruiter-driven stage transitions were not exercised; a fault in review/assessment/interview/decision paths would not have surfaced here.
Not covered by this report
- •Email delivery outcomes are not instrumented: only send failures are counted, with no volume of successful sends, bounces, complaints, or SES throttling. emailsFailed = 0 does not prove candidates received their stage-transition emails.
- •Pipeline stage transitions beyond 'submitted' (under review, assessment, interview, decision) have no counters here, and with zero staff activity these paths were neither observed nor exercised.
- •Only averages/min/max are available — no p95/p99 and no per-endpoint or per-route breakdown — so the 989.9ms peak cannot be attributed to a specific operation, and a small set of chronically slow endpoints could be hidden inside a healthy-looking average.
- •No ALB-level or ECS lifecycle data: target health, connection errors, 5xx generated by the load balancer itself, task restarts, OOM kills, or deployments during the window are all unobserved. Health checks came from a probe, not from the balancer's view.
- •No application error logs, exception counts, or background/queue metrics (job backlog, retry depth, worker health), so a failing async worker that never returns an HTTP error would look identical to a healthy system in this report.
healthy9/25/2026, 1:07:19 PM — 1:37:57 PM50d ago
TaliLink stayed up for the whole 30-minute window: no failed health checks, no 5xx errors on either the API or the website, and no failed registrations, applications, or emails were recorded. Infrastructure is running cool (containers ~3% CPU, database ~4% CPU, 3 tasks steady). One thing needs human attention but is not currently breaking anything: the backup email account cannot log in, so if the main email provider (SES) stops working, stage-transition emails to candidates would have no fallback. Someone should replace that app password. Also note this window saw only candidate traffic — no staff were active — so the recruiter-facing side of the pipeline was effectively untested during this period.
Findings
No email failover available
Open warning alert: Workspace SMTP rejected the backup password. SES is still delivering and observed email failures were 0 across all 30 snapshots, so there is no current impact — but the redundancy for candidate stage-transition email is gone until the app password is replaced.
Application-layer latency tail well above the median
API application response time averaged 249 ms but peaked at 1253.6 ms, while ALB-level health probes stayed at 22–48 ms. Consistent with a small number of slow endpoints or queries rather than systemic load, since container and DB CPU never exceeded 4.2% and 5.7%.
Database write latency spikes
Write latency averaged 7.08 ms with a max of 34.2 ms, against read latency of ~0.13 ms. Small absolute numbers and likely burst-related, but it is the only DB metric showing variance and could be the same events behind the latency tail.
Low-level 4xx traffic, no 5xx
API 4xx ran at roughly 1.4 responses per minute, peaking around 7 per minute; the web tier around 0.8 per minute, peaking around 9. 5xx stayed at 0 per minute throughout. These are sampled rates — a period total is not measurable from this data. Likely routine auth/validation rejections, but the reason breakdown is not captured.
Zero staff activity for the entire window
activeStaff was 0 in all 30 snapshots while candidate activity continued (2–9 active talents, registrations recorded in every snapshot). Staff-driven pipeline transitions — review, assessment, interview, decision — and the emails they trigger were therefore not exercised, so their health is unproven rather than confirmed.
Not covered by this report
- •Email delivery outcome is not instrumented beyond send attempts: bounces, spam placement, SES throttling/quota, and provider-side rejections would not appear here. 'emailsFailed: 0' means no failure the app noticed, not confirmed inbox delivery.
- •No per-route or per-endpoint latency breakdown, no traces, and no slow-query log. The 1253.6 ms peak cannot be attributed to a specific endpoint, query, or external call from this data.
- •No ALB-level metrics (target connection errors, rejected/surged connections, 4xx/5xx generated by the load balancer itself) and no client-side Next.js error reporting — failures that never reach the application would be invisible here.
- •Staff-side pipeline behaviour is unobserved this window (activeStaff was 0 throughout), and stage-transition success/failure counters other than registrations and applications are not reported at all. Silence here is absence of traffic, not evidence of correctness.
- •No background job/queue depth, RDS free storage, connection-pool saturation, or deploy/restart event data. DB connections sat flat at exactly 9 for all 30 samples, which is plausible for a small pool but cannot be distinguished from a stale or capped reading using this data alone.
healthy9/25/2026, 12:36:11 PM — 1:06:48 PM50d ago
TaliLink stayed up and served every request for the full 30-minute window: no failed requests (no 5xx), no failed registrations, applications or emails, and both the containers and the database were running well below capacity. Two things are worth attention rather than alarm: some API calls were slow (a worst case of about 1.8 seconds while the typical health check answered in 33ms), and the open alert about the backup email login is still unresolved — mail is going out via SES, but there is no second path if SES has a problem. No staff accounts were active during this window, so the recruiter-side of the pipeline was not exercised and cannot be declared healthy from this data.
Findings
No errors or downtime observed
API was reachable in all 30 snapshots (100% uptime), with 5xx at 0 per minute on both API and web throughout. 4xx ran low — about 0.8/min on the API (peak 4/min) and about 1.8/min on the web tier (peak 14/min), consistent with normal client-side noise; the period total is not measurable from sampled rates.
Application request latency has a long tail
Measured API request time averaged ~414ms with a maximum of ~1760ms, while the lightweight availability probe averaged only 33ms. This gap is consistent with a subset of heavier endpoints (or cold paths) being slow rather than a system-wide slowdown, but with only min/avg/max available the percentile shape is unknown.
Email failover is unavailable (open alert)
Workspace SMTP rejected the backup app password, so SES is currently a single point of failure for candidate transactional email. Nothing in this window shows email failing (emailsFailed was 0 per snapshot), but a SES disruption would have no fallback until the app password is replaced.
Infrastructure is far from any limit
ECS held a steady 3 tasks at ~2.4% CPU and ~23.8% memory; RDS sat at ~4.5% CPU, a flat 9 connections, and ~950MB freeable memory. Headroom is ample; none of the latency above is explained by resource pressure at these levels.
Database write latency spikes intermittently
Write latency averaged 7.3ms but peaked at 37.9ms while reads stayed near 0.2ms. Likely bursty write activity or EBS burst behaviour; it is not currently harmful, but it is the only storage-side signal trending away from baseline and may contribute to the slower API requests.
Not covered by this report
- •No staff users were active at any point (activeStaff was 0 for all 30 snapshots), so stage transitions, review/assessment/interview/decision actions, and the emails they trigger were almost certainly never exercised — their health is unknown, not confirmed.
- •There is no email *success* or delivery metric, only emailsFailed. A zero failure count does not prove mail was sent, accepted by SES, or delivered; bounce, complaint and SES throttling rates are not instrumented here.
- •Only min/avg/max latency is reported — no p95/p99 and no per-endpoint or per-route breakdown, so which requests produced the ~1.8s peak, and how often such peaks occur, cannot be determined from this data.
- •No ALB-level metrics (target 5xx vs LB 5xx, healthy host count, connection errors, rejected connections) and no ECS task restart/OOM-kill counts are present, so a task flapping and being replaced within a snapshot interval would not be visible.
- •Web-tier response time was captured in only 25 of 30 snapshots; the 5 missing samples are unknown, not healthy. Likewise there is no browser/client-side error, RDS disk/IOPS, or background-job/queue-depth instrumentation in this feed.
degraded9/25/2026, 12:05:03 PM — 12:35:44 PM50d ago
TaliLink stayed up for the whole window — every health check succeeded, no server errors were recorded, and registrations and applications kept completing with zero failures. Two things stop this from being a clean bill of health: some individual API requests took as long as 8 seconds (most were fast, so this affected a minority of users), and the backup email login is still broken, so if the main email provider stops working there is no fallback and candidates would silently stop receiving stage-transition emails. Neither is an emergency; both should be looked at today.
Findings
API latency outlier up to 8.2s despite trivial load
Application request latency averaged 466ms but peaked at 8214.8ms, while the ALB health probe stayed at 21–109ms and CPU/memory sat near idle (2.7% CPU, 23% memory, 3 tasks). Consistent with a slow individual endpoint or query rather than saturation; no per-route or percentile breakdown is available to confirm.
No email failover — backup SMTP login rejected
Open alert: Workspace SMTP rejected the backup app password. SES is reportedly still sending, but there is no redundancy for candidate transactional email until the app password is replaced.
4xx responses present, 5xx absent
API returned roughly 2.3 client errors per minute, peaking around 8 per minute; web tier about 0.2 per minute, peaking at 6. Server errors (5xx) were 0 per minute throughout. These are sampled rates — a period total is not measurable from this data, and no failure-reason breakdown was captured.
Database healthy but write latency is spiky
RDS CPU 3.9–6.3%, a flat 9 connections, ~960MB freeable memory, read latency ≤3.3ms. Write latency averaged 6.65ms with a 33.2ms peak — well within tolerance, but the spikiness is worth correlating with the 8.2s API outlier.
Zero staff activity — pipeline stages were not exercised
Active staff was 0 across all 30 snapshots while 4–7 candidates were active. Registrations (avg ~7.8) and submissions (avg ~1.8) succeeded, but no data here demonstrates that review, assessment, interview, or decision transitions — or the emails they trigger — actually work.
Not covered by this report
- •Email delivery is only observed as 'emailsFailed = 0'. There is no metric for emails attempted, sent, bounced, or delivered, so zero failures could equally mean zero emails were sent; SES health itself is unmonitored here.
- •Latency is reported only as min/avg/max with no percentiles, no per-endpoint or per-route breakdown, and no trace IDs — the 8.2s request cannot be attributed to a specific operation from this data.
- •No load balancer-side metrics (target 5xx, connection errors, rejected connections, target health flaps). A request that failed before reaching the app would not appear in these counters.
- •Stage transitions beyond 'submitted' are not instrumented (no counters for under-review, assessment, interview, decision), and staff activity was zero, so the mid- and late-pipeline paths are entirely unobserved rather than confirmed working.
- •No background job/queue metrics (queue depth, retries, dead letters) and no slow-query or connection-pool-wait telemetry, so a backlog or pool contention behind the latency spike would be invisible here.
healthy9/25/2026, 11:33:59 AM — 12:04:37 PM50d ago
TaliLink served every request during this ~30 minute window: no failed health checks, no 5xx errors on either the API or the website, and no failed registrations, applications, or emails. Infrastructure is running cold (CPU under 4%, 3 tasks steady, database connections flat at 9), so there is plenty of headroom. Two things need a human: one open alert says the backup email login is rejected, so if the primary sender (SES) fails there is no fallback — someone should replace that app password; and there were short bursts of client-side (4xx) errors and slow API responses worth a glance, though nothing broke.
Findings
No failures across availability, errors, or workflows
100% uptime over 30 snapshots, 0 unreachable cycles, and HTTP 5xx held at 0 per minute on both API and web for every sample. Registrations (avg ~6 succeeded per snapshot), application submissions, and transactional emails recorded zero failures.
Email failover is unavailable (open alert)
Workspace SMTP is rejecting the backup password, so SES is currently the only sending path. This is a single-point-of-failure risk, not a current outage — email failures are still at zero — but a SES problem would silently stop stage-transition emails until the app password is replaced.
API tail latency spikes to ~1.5s
Application-path API response time averaged 282ms but peaked at 1526ms, while the lightweight health probe stayed at 23-44ms. The gap is consistent with a small number of heavy endpoints or queries rather than a general slowdown; per-route data would be needed to confirm.
Bursty 4xx rate on the API
API 4xx averaged about 3.7 per minute but peaked at roughly 83 per minute in at least one sample; web 4xx was lower, averaging under 1 per minute with a peak near 7. The period total is not measurable from this sampled data. Likely candidates are validation rejections, expired auth tokens, or a scanner/bot, but the reason is not broken out here.
Database write latency variable on an otherwise idle instance
RDS write latency averaged 8.44ms with a peak of 39.6ms while read latency stayed near 0ms and CPU under 7%. With only 9 connections and ~970MB freeable memory, this looks like EBS burst/IO variability rather than load pressure, but it is worth watching if it trends upward.
Not covered by this report
- •Email send volume and delivery outcomes: only 'emailsFailed' is tracked (at 0). There is no count of emails actually sent, no SES bounce/complaint/deferral data, and no confirmation that stage-transition emails reached candidate inboxes — silent non-delivery would look identical to health here.
- •No per-endpoint or per-status-code breakdown, so the 4xx bursts and the 1526ms latency peak cannot be attributed to a specific route, tenant, or client. Nothing here distinguishes legitimate validation errors from auth failures or bot traffic.
- •Pipeline stages beyond submission are uninstrumented: only registrations and applications-submitted are counted. Movement through under review, assessment, interview, and decision — and any stalling there — is not observable from this data.
- •Load-balancer-level metrics (ALB 5xx, target health, rejected/dropped connections, TLS errors) are absent. Requests that failed before reaching the NestJS tasks would not appear in these API counters, so 'zero 5xx' covers the application only.
- •'activeStaff' reads 0 for every snapshot. This may genuinely mean no recruiter was logged in during a quiet window, or the signal may not be wired up — it should not be read as evidence that staff-facing flows work. There is also no background-job/queue depth, no container restart or OOM-kill count, and no log or trace correlation to confirm nothing failed asynchronously.
healthy9/25/2026, 11:02:53 AM — 11:33:31 AM50d ago
Over the ~30 minutes monitored, TaliLink stayed up the whole time: no failed checks, no server errors, and candidates were registering and applying without failures. Infrastructure is running cool (containers ~3% CPU, database ~4.5% CPU, 3 tasks steady). The one thing needing human action is not an outage: the backup email login is rejected, so email is currently sending through SES with no fallback if SES has a problem. Nothing here was fixed or changed — this is a read-only assessment.
Findings
No email failover — backup SMTP credentials rejected
Open alert states Workspace SMTP rejected the backup password; SES is still delivering and emailsFailed stayed at 0 across all 30 snapshots. This is a single-point-of-failure risk for stage-transition email, not a current delivery failure. Replacing the app password is the action item.
Availability and error rates clean
0 unreachable cycles, 100% uptime, API health probe 21–70 ms (avg 33 ms). HTTP 5xx was 0 per minute on both API and web for every sample; 4xx averaged about 1.6/min on the API (peak 9/min) and about 1.5/min on the web tier (peak 10/min), consistent with normal client-side noise such as auth and validation. Totals are not derivable from these sampled rates.
API latency outlier at ~965 ms against a ~96 ms average
API request latency averaged 95.6 ms but peaked at 964.6 ms in at least one snapshot, while DB write latency peaked at 37 ms against a 5.9 ms average. Likely a cold path or a single slow query/email-send rather than systemic load, since CPU, memory, and connections were flat — but there is no per-endpoint breakdown to confirm.
Ample infrastructure headroom
Containers held 2.1–4.4% CPU and ~23% memory with 3 tasks running throughout; RDS held 9 connections constantly, 3.96–5.53% CPU, and ~961–972 MB freeable memory. Load (API ~32 req/min avg, peak 73; web ~33 req/min avg, peak 112) is well inside capacity.
Zero staff activity for the entire window
activeStaff was 0 in all 30 snapshots while activeTalents averaged 4.4 (peak 9). Off-hours or a quiet period is the plausible explanation, but it means recruiter-side flows — and therefore most pipeline stage transitions and their emails — were effectively unexercised and untested by this data.
Not covered by this report
- •Email delivery outcomes are not observable: emailsFailed only counts send attempts the app recorded as failed. Bounces, SES throttling/quota, spam placement, and whether candidates actually received stage-transition mail are not instrumented — 0 failures is not proof of delivery.
- •Pipeline stage transitions beyond submission are not reported. There are no counters for under review, assessment, interview, or decision, so stalled or silently failing mid-pipeline movement would be invisible here, especially with activeStaff at 0.
- •No per-endpoint or percentile latency breakdown. The 964.6 ms peak cannot be attributed to a route, query, or dependency, and p95/p99 cannot be derived from min/avg/max alone.
- •No ALB, target-group, or per-task telemetry (healthy host count, 5xx at the load balancer, connection errors, task restarts/OOM kills). Container averages across 3 tasks would mask one unhealthy task.
- •topFailureReasons and collectionErrors are empty, meaning nothing was recorded — not that failure-reason coverage was verified. Also unmeasured: background jobs/queue depth, resume/file uploads, third-party integrations, and any total counts, since the load figures are overlapping sampled rates.
degraded9/25/2026, 10:32:23 AM — 11:02:29 AM50d ago
TaliLink stayed up for the whole 30-minute window — no failed requests, no server errors, no failed registrations or applications, and plenty of spare CPU, memory and database capacity. The one real problem is speed: some API calls were very slow, with at least one taking over 17 seconds while the average sat near one second. Separately, the backup email sender still cannot log in, so if the primary email provider (SES) stops working, stage-transition emails to candidates would go nowhere. Neither issue needs an emergency response, but both need an owner today.
Findings
API application response times are slow and highly variable
API response time averaged 1049 ms across 29 samples with a maximum of 17455 ms, against a minimum of 5 ms. With only min/avg/max available the shape of the tail is unknown, but a 17-second call alongside a 5 ms floor is consistent with a small number of pathological requests rather than uniform slowness.
Slowness is not explained by resource pressure
ECS CPU peaked at 4.14% and memory at 23.41% across a steady 3 tasks; RDS CPU peaked at 5.9% with a flat 9 connections and ~960 MB freeable memory. Nothing in the infrastructure metrics accounts for the multi-second responses, so the cause is likely in application or query behaviour, or an external dependency — this data cannot distinguish between them.
Database write latency spikes to 32 ms
Write latency averaged 7.09 ms but peaked at 32.4 ms, while read latency stayed at 0.26 ms average / 2.5 ms max. This is not alarming on its own, but it is the only backend signal that moves in step with the slow responses and is worth correlating against the slow request timestamps.
Email failover is broken (open alert)
Workspace SMTP is rejecting the backup app password. SES is still sending and emailsFailed was 0 in every snapshot, so candidates are currently receiving stage-transition mail — but there is no second path if SES degrades. Replacing the app password is a low-effort, high-value fix.
No staff activity observed — pipeline stages beyond submission were not exercised
activeStaff was 0 in all 29 snapshots while active talents averaged 6.86. Candidate-facing registration and application flows were genuinely exercised; the review, assessment, interview and decision transitions were not, so their health is untested rather than confirmed good.
Not covered by this report
- •No percentile latency (p50/p95/p99) is instrumented — only min, avg and max per snapshot. The number of requests affected by the multi-second responses is not measurable from this data.
- •No per-endpoint or per-route breakdown, and no database slow-query log or trace data. Which operation produced the 17.5-second response cannot be identified here.
- •Email delivery outcomes are not observed beyond an emailsFailed counter of 0 — SES bounces, complaints, deferrals and actual candidate inbox delivery are not instrumented, so 'no failures' means 'no send errors recorded', not 'mail arrived'.
- •No background job, queue-depth or retry metrics are present. Work that is queued and silently stalling (e.g. delayed stage-transition emails) would not appear in these numbers.
- •4xx and 5xx figures are sampled per-minute rates with overlapping samples (API ~1.93/min peaking at 11; web ~1.83/min peaking at 7; 5xx flat at 0). Period totals are not derivable from this data, and no breakdown of which 4xx status codes or paths is available.
degraded9/25/2026, 10:01:06 AM — 10:31:45 AM50d ago
TaliLink stayed up for the whole 30-minute window: no failed API checks, no server errors, and no failed registrations, applications, or email sends were recorded. The one thing needing action is the open alert: the backup email login is rejected, so email is running on a single path (SES) with no fallback — if SES has a problem, candidates stop receiving stage-transition email. Separately, a small number of requests were unusually slow (up to ~1.8s) even though the servers and database were nearly idle, which is worth a look but is not currently breaking anything.
Findings
No email failover — backup SMTP credentials rejected
Open warning alert: Workspace SMTP rejected the backup app password, so SES is the only working send path. Observed emailsFailed was 0 per snapshot, but that counter only reflects send attempts that failed in-app; it does not prove the backup path works or that mail was delivered.
Application-path latency tail far above baseline
API request latency averaged 269.5ms but peaked at 1764.8ms, while the health/availability probe stayed at 25–50ms. With container CPU at ~2.7% and DB CPU at ~4.5%, this is likely specific slow endpoints or queries rather than resource contention — but only min/avg/max is available, so the number of affected requests is unknown.
Steady 4xx trickle with no cause breakdown
Client errors ran at about 2 per minute on the API, peaking at 12 per minute, plus about 1.5 per minute on the web tier peaking at 7. No failure reasons were captured, so validation errors, auth rejections, 404 scanning, and genuine user-facing breakage are indistinguishable. A period total is not measurable from this sampled data.
activeStaff reported as 0 in all 30 snapshots
Talent activity ranged 3–9 concurrent users, but staff activity was flat 0 for the entire window. This is consistent with genuinely no recruiter being online at this hour, but a permanently-zero gauge can also mean the signal is not being reported; the data cannot distinguish the two.
Infrastructure idle with intermittent DB write latency spikes
3 ECS tasks steady, CPU 2.2–3.9%, memory ~21%, DB connections pinned at exactly 9 (likely pool floor, never grew). DB write latency averaged 6.71ms but spiked to 34.4ms; against this load level that is worth correlating with the 1.8s request peak, though causation is not shown by the data.
Not covered by this report
- •Email delivery outcomes are not observed: SES bounces, complaints, deferrals, and per-stage-transition send success are not instrumented. A zero emailsFailed counter does not mean candidates received their mail.
- •Only min/avg/max latency is available — no p95/p99 and no per-endpoint or per-route breakdown, so it is impossible to tell whether the 1764.8ms peak hit one request or a meaningful slice of candidate traffic.
- •No classification of the 4xx responses (no failure reasons, no status-code or path breakdown), so user-impacting errors such as failed logins or rejected uploads cannot be separated from harmless noise or bot scanning.
- •No pipeline-stage progression metrics: registrations and applications are counted, but transitions through under review / assessment / interview / decision are not, so a stage that has silently stalled would not appear here.
- •No ALB-level, background-job, or client-side visibility: target-group 5xx vs app 5xx, connection rejects, queue depth/retries, DB slow-query and lock data, and Next.js browser errors are all uninstrumented in this dataset.