Feat: Uptime Pipeline #2812
Feat: Uptime Pipeline #2812
Conversation
Br0wnHammer
requested review from
ajhollid,
mohicody,
Owaiseimdad and
karenvicent
as code owners
WalkthroughSwitches uptime-details aggregation to use Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Server
participant MongoDB
Client->>Server: Request uptime details
Server->>MongoDB: Aggregation pipeline\n($match by createdAt -> $lookup(monitor) -> $dateToString grouping -> per-bucket $group -> overall $group -> $project)
Note right of MongoDB: Computes buckets array, per-bucket totals/averages,\naccumulates overall totals, computes uptimePercentage and avgResponseTime
MongoDB-->>Server: Aggregated result (buckets, totals, computed fields)
Server-->>Client: Response with uptimePercentage, groupedAvgResponseTime, groupedChecks/up/down
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Joke: A Canadian and an American walked into a code review — the Canadian politely fixed the bug and apologised for breaking the build, while the American congratulated them for being so modest. Pre-merge checks (1 passed, 1 warning, 1 inconclusive)❌ Failed Checks (1 warning, 1 inconclusive)
✅ Passed Checks (1 passed)
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
server/src/db/mongo/modules/monitorModuleQueries.js (1)
113-121:groupedUptimePercentageis projected from a structure that no longer exists.
$arrayElemAt: ["$uptimePercentage.percentage", 0]assumesuptimePercentageis an array of objects with apercentagefield. In this refactor,uptimePercentageis a scalar computed in the prior $project. This will error at runtime.Apply this diff:
- groupedUptimePercentage: { $arrayElemAt: ["$uptimePercentage.percentage", 0] }, + groupedUptimePercentage: "$uptimePercentage",
🧹 Nitpick comments (3)
server/src/db/mongo/modules/monitorModuleQueries.js (3)
12-15: Remove unnecessary pre-group sort; add explicit sort by bucket after grouping for stable ordering.Sorting before a $group is wasted work here and doesn’t guarantee output order. Sort buckets after the first $group to ensure
groupedChecksare chronologically ordered.Apply this diff:
- { - $sort: { - updatedAt: 1, - }, - }, @@ }, + { + $sort: { "_id.bucket": 1 } + }, { $group: {Also applies to: 31-33
49-66: Naming nit:totalChecksinside groupedUpChecks/Down actually represents only up/down counts.Using
totalChecksto mean “up checks” or “down checks” is ambiguous and can confuse consumers.Consider renaming to
countfor clarity:- totalChecks: "$$b.upChecks", + count: "$$b.upChecks", @@ - totalChecks: "$$b.downChecks", + count: "$$b.downChecks",If the UI relies on
totalChecks, skip this and we can add a TODO for later.Also applies to: 66-82
6-9: Performance reminder: ensure supporting index exists.For
checkscollection, this pipeline benefits from a compound index on{ monitorId: 1, updatedAt: 1 }to accelerate$matchand avoid in-memory sorts.If you want, I can prep the index migration snippet and a quick readme note.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
server/src/db/mongo/modules/monitorModuleQueries.js(2 hunks)
🔇 Additional comments (1)
server/src/db/mongo/modules/monitorModuleQueries.js (1)
48-48: Potential shape mismatch:groupedChecksstill contains_id: { bucket: <string> }.Previously,
_idmight have been the bucket string itself. If the UI expects_idto be the date string, this change can break charts.Would you prefer to flatten
_idnow? Example adjustment (optional):- groupedChecks: "$buckets", + groupedChecks: { + $map: { + input: "$buckets", + as: "b", + in: { + _id: "$$b._id.bucket", + totalChecks: "$$b.totalChecks", + upChecks: "$$b.upChecks", + downChecks: "$$b.downChecks", + avgResponseTime: "$$b.avgResponseTime" + } + } + },
![llamapreview[bot]](https://avatars.githubusercontent.com/in/1023541?s=60&v=4){kind=small}
There was a problem hiding this comment.
Auto Pull Request Review from LlamaPReview
1. Overview
1.1 Core Changes
- Primary purpose and scope: Optimize uptime monitoring pipeline to reduce processing time and improve UI responsiveness
- Key components modified: MongoDB aggregation pipeline in
monitorModuleQueries.js - Cross-component impacts: Affects uptime metrics calculation and dashboard visualization
- Business value alignment: Improves user experience by reducing UI lag for real-time monitoring
1.2 Technical Architecture
- System design modifications: Replaces multi-pass $facet pipeline with optimized single-pass aggregation
- Component interaction changes: Reduces database load for monitor checks processing
- Integration points impact: Preserves output structure for frontend compatibility
- Dependency changes and implications: No new dependencies introduced
2. Critical Findings
2.1 Must Fix (P0🔴)
Issue: Incorrect response time calculation (averaging bucket averages)
- Analysis Confidence: High
- Impact: Produces mathematically incorrect metrics that misrepresent system performance
- Resolution: Calculate response time sums per bucket and compute overall average correctly
Issue: Missing response time segmentation for up/down checks
- Analysis Confidence: High
- Impact: Uses same response time for successful/failed checks, distorting metrics
- Resolution: Track separate response time sums for up/down statuses
Issue: Changed bucketing field from createdAt to updatedAt
- Analysis Confidence: Medium
- Impact: Potential data misalignment if checks are updated after creation
- Resolution: Revert to createdAt for bucketing consistency
2.2 Should Fix (P1🟡)
Issue: Missing bucket sorting
- Analysis Confidence: High
- Impact: Time series data may appear out-of-order in UI visualizations
- Suggested Solution: Add explicit sort stage after bucket grouping
Issue: Potential memory overflow with large datasets
- Analysis Confidence: Medium
- Impact: Pipeline could OOM when processing large time ranges
- Suggested Solution: Implement bucket limit safeguard
2.3 Consider (P2🟢)
Area: Testing coverage
- Analysis Confidence: High
- Improvement Opportunity: Prevent regressions with pipeline validation tests
Area: Pipeline documentation
- Analysis Confidence: High
- Improvement Opportunity: Improve maintainability with inline comments
2.4 Summary of Action Items
- Immediate (P0): Fix response calculations, revert to createdAt, add segmentation
- High Priority (P1): Add bucket sorting, implement memory safeguards
- Follow-up (P2): Add tests and documentation
3. Technical Analysis
3.1 Code Logic Analysis
📁 server/src/db/mongo/modules/monitorModuleQueries.js - getMonitorChecksPipeline
- Submitted PR Code:
{
$group: {
_id: {
bucket: {
$dateToString: {
format: dateString,
date: "$updatedAt", // Uses updatedAt instead of createdAt
},
},
},
avgResponseTime: { $avg: "$responseTime" },
}
},
{
$group: {
_id: null,
avgResponseTime: { $avg: "$avgResponseTime" }, // Incorrect average
}
}- Analysis:
- Current logic averages per-bucket averages instead of calculating overall average
- Uses updatedAt instead of createdAt for bucketing
- Missing segmentation between up/down check response times
- No sorting of time buckets
- Risk of memory overflow with $push of all buckets
- LlamaPReview Suggested Improvements:
// First group stage (per bucket)
{
$group: {
_id: {
bucket: {
$dateToString: {
format: dateString,
date: "$createdAt", // Revert to createdAt
},
},
},
upResponseSum: {
$sum: {
$cond: [{ $eq: ["$status", true] }, "$responseTime", 0]
}
},
downResponseSum: {
$sum: {
$cond: [{ $eq: ["$status", false] }, "$responseTime", 0]
}
},
// ... other metrics
}
},
{ $sort: { "_id.bucket": 1 } }, // Add sorting
{ $limit: 1000 }, // Add safeguard
// Second group stage (overall)
{
$group: {
_id: null,
avgResponseTime: { $avg: "$responseTime" }, // Correct overall average
// ... other aggregates
}
}- Improvement rationale:
- Technical benefits: Fixes mathematical errors, ensures chronological ordering
- Business value: Provides accurate monitoring metrics for decision-making
- Risk assessment: Prevents OOM errors and maintains data consistency
3.2 Key Quality Aspects
- System scalability considerations: Added bucket limit prevents memory issues
- Performance bottlenecks and optimizations: Reduced pipeline stages improve efficiency
- Testing strategy and coverage: Critical need for aggregation pipeline tests
- Documentation needs: Requires inline comments explaining pipeline logic
4. Overall Evaluation
- Technical assessment: Good architectural approach but contains critical calculation flaws
- Business impact: Essential optimization for UI responsiveness but must ensure metric accuracy
- Risk evaluation: High - current implementation produces misleading metrics
- Notable positive aspects: Effective pipeline simplification, preserves output structure
- Implementation quality: Needs improvement for mathematical correctness and edge cases
- Final recommendation: Request Changes - Must fix critical P0 issues before merging
💡 LlamaPReview Community
Have feedback on this AI Code review tool? Join our GitHub Discussions to share your thoughts and help shape the future of LlamaPReview.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
server/src/db/mongo/modules/monitorModuleQueries.js (2)
73-77: Standardize uptimePercentage scale and zero-check semanticsYou emit uptimePercentage as a 0–1 ratio (good), but for totalChecks == 0 you return 0. Downstream code sometimes multiplies by 100 and sometimes appends “%” to raw values. This creates “0.85% vs 85%” bugs and “no data” looking like 0%.
Pick one:
- Always 0–1 ratio; when totalChecks == 0, return null (no data) or 1 (optimistic).
- Or always 0–100 percent; ensure all consumers expect that.
If you choose ratio + null on no data, adjust as:
- uptimePercentage: { - $cond: [{ $eq: ["$totalChecks", 0] }, 0, { $divide: ["$upChecks", "$totalChecks"] }], - }, + uptimePercentage: { + $cond: [{ $eq: ["$totalChecks", 0] }, null, { $divide: ["$upChecks", "$totalChecks"] }], + },And confirm MonitorsTable and Host components convert consistently before rendering.
Want me to scan client usage and open a small PR to normalize formatting?
Also applies to: 157-163
19-22: Add explicit timezone to $dateToString and thread a tz parameterBuckets will default to UTC without timezone, which often doesn’t match UI expectations. Thread a tz (e.g., from user/team settings) and pass it to $dateToString.
-const buildUptimeDetailsPipeline = (monitorId, dates, dateString) => { +const buildUptimeDetailsPipeline = (monitorId, dates, dateString, tz) => {$dateToString: { format: dateString, - date: "$updatedAt", + date: "$updatedAt", + timezone: tz, },Run this to locate callers to update their signatures to include timezone:
#!/bin/bash rg -n -C2 '\bbuildUptimeDetailsPipeline\s*\('I can provide a small shim that falls back to a default tz while you wire through settings.
Also applies to: 3-3
🧹 Nitpick comments (2)
server/src/db/mongo/modules/monitorModuleQueries.js (2)
93-109: Naming nit: “totalChecks” inside groupedUpChecks is ambiguousThe objects in groupedUpChecks use totalChecks to mean “number of up checks in this bucket.” Consider renaming that field to count to avoid confusion with the bucket’s totalChecks field.
This is a schema change; only do it if consumers are ready.
I can grep usages and stage a follow-up if you want to adopt clearer naming.
12-15: Optional: drop the pre-group sort for better performanceYou sort by updatedAt before a $group that only uses $sum/$avg; that sort is unnecessary and adds cost. You already sort bucket keys after grouping.
Consider removing this sort unless a downstream accumulator depends on order.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
server/src/db/mongo/modules/monitorModuleQueries.js(2 hunks)
|
@ajhollid I have updated the query logic. Please review when possible. |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
server/src/db/mongo/modules/monitorModuleQueries.js (3)
12-18: Add explicit timezone to date buckets$dateToString defaults to UTC, which can shift daily/hourly buckets vs. the UI. Pass a timezone.
-const buildUptimeDetailsPipeline = (monitorId, dates, dateString) => { +const buildUptimeDetailsPipeline = (monitorId, dates, dateString, tz = "UTC") => { return [ { $group: { _id: { $dateToString: { format: dateString, - date: "$createdAt", + date: "$createdAt", + timezone: tz, }, },
41-66: Invalid self-reference to $buckets inside $group; compute weighted sum insteadYou can’t reference $buckets while defining it; and the current logic averages weighted terms by bucket count (wrong). Aggregate a streaming weighted sum, then divide later.
$group: { _id: null, buckets: { $push: "$$ROOT" }, totalChecks: { $sum: "$totalChecks" }, upChecks: { $sum: "$upChecks" }, downChecks: { $sum: "$downChecks" }, - overallAvgResponseTime: { - $avg: { - $map: { - input: { $range: [0, { $size: { $ifNull: ["$buckets", []] } }] }, - as: "i", - in: { - $let: { - vars: { bucket: { $arrayElemAt: ["$buckets", "$$i"] } }, - in: { $multiply: ["$$bucket.avgResponseTime", "$$bucket.totalChecks"] }, - }, - }, - }, - }, - }, + sumWeightedResponseTime: { $sum: { $multiply: ["$avgResponseTime", "$totalChecks"] } }, },
68-86: Guard divide-by-zero and use the weighted sum for groupedAvgResponseTime$divide by 0 can error. Also no need to $reduce over buckets after the fix above.
$project: { _id: 0, uptimePercentage: { $cond: [{ $eq: ["$totalChecks", 0] }, 0, { $divide: ["$upChecks", "$totalChecks"] }], }, - groupedAvgResponseTime: { - $divide: [ - { - $reduce: { - input: "$buckets", - initialValue: 0, - in: { $add: ["$$value", { $multiply: ["$$this.avgResponseTime", "$$this.totalChecks"] }] }, - }, - }, - "$totalChecks", - ], - }, + groupedAvgResponseTime: { + $cond: [ + { $eq: ["$totalChecks", 0] }, + 0, + { $divide: ["$sumWeightedResponseTime", "$totalChecks"] } + ] + }, groupedChecks: "$buckets",
🧹 Nitpick comments (1)
server/src/db/mongo/modules/monitorModuleQueries.js (1)
8-11: Confirm intended time field (createdAt) and add indexYou switched matching to createdAt. If that’s the intended “time of record,” great—just confirm UI/analytics expect this (not updatedAt). Also ensure a compound index exists on checks: { monitorId: 1, createdAt: 1 } to keep this fast over large ranges. Americans argue about BBQ; Canadians quietly add the index and smile.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
server/src/db/mongo/modules/monitorModuleQueries.js(2 hunks)
🔇 Additional comments (6)
server/src/db/mongo/modules/monitorModuleQueries.js (6)
19-33: Per-bucket stats look goodThe conditional avgs ignore nulls as expected; filters later handle zero-count buckets.
36-38: Sort by bucket id is fineString sort is OK if format is zero-padded ISO-like.
70-72: Standardize uptimePercentage scale and empty-state semanticsYou emit a 0–1 ratio and 0 when no data. Confirm the client expects a ratio (and not 0–100) and whether no-data should be 1, 0, or null. Canadians would pick one polite convention and stick to it.
87-104: Up buckets mapping is correctFiltered to positive upChecks; fields are minimal and useful.
105-121: Down buckets mapping is correctMirrors the up path; consistent.
152-159: Final projection fields OKNames are consistent with earlier projection; just ensure consumers use groupedUptimePercentage (ratio) consistently.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
server/src/db/mongo/modules/monitorModuleQueries.js (3)
8-17: Consistent timestamp field — good correctionMatching/sorting/bucketing all on createdAt is now aligned. Nice.
Also applies to: 36-38
14-17: Add explicit timezone to $dateToString (avoid silent UTC shifts)Without timezone, buckets default to UTC and can appear “off by one” day/hour for users. Pass tz and default it. Canadians politely adapt; Americans open a ticket.
-const buildUptimeDetailsPipeline = (monitorId, dates, dateString) => { +const buildUptimeDetailsPipeline = (monitorId, dates, dateString, tz) => { @@ $dateToString: { format: dateString, - date: "$createdAt", + date: "$createdAt", + timezone: tz ?? "UTC", },Run to find and update callers to pass a timezone (team/user setting or config):
#!/bin/bash rg -n 'buildUptimeDetailsPipeline\(' -C2
12-32: Fix “average of averages” — compute weighted average insteadgroupedAvgResponseTime currently averages per-bucket averages, biasing results when bucket sizes differ. Carry response-time sums and divide once.
@@ $group: { _id: { $dateToString: { format: dateString, date: "$createdAt", }, }, totalChecks: { $sum: 1 }, upChecks: { $sum: { $cond: [{ $eq: ["$status", true] }, 1, 0] } }, downChecks: { $sum: { $cond: [{ $eq: ["$status", false] }, 1, 0] } }, avgResponseTime: { $avg: "$responseTime" }, + sumResponseTime: { $sum: "$responseTime" }, avgUpResponseTime: { $avg: { $cond: [{ $eq: ["$status", true] }, "$responseTime", null], }, }, avgDownResponseTime: { $avg: { $cond: [{ $eq: ["$status", false] }, "$responseTime", null], }, }, }, @@ $group: { _id: null, buckets: { $push: "$$ROOT" }, totalChecks: { $sum: "$totalChecks" }, upChecks: { $sum: "$upChecks" }, downChecks: { $sum: "$downChecks" }, + totalResponseTime: { $sum: "$sumResponseTime" }, }, @@ $project: { _id: 0, uptimePercentage: { $cond: [{ $eq: ["$totalChecks", 0] }, 0, { $divide: ["$upChecks", "$totalChecks"] }], }, - groupedAvgResponseTime: { - $avg: { - $map: { - input: "$buckets", - as: "b", - in: "$$b.avgResponseTime", - }, - }, - }, + groupedAvgResponseTime: { + $cond: [ + { $eq: ["$totalChecks", 0] }, + 0, + { $divide: ["$totalResponseTime", "$totalChecks"] } + ] + },Also applies to: 41-47, 50-63
🧹 Nitpick comments (4)
server/src/db/mongo/modules/monitorModuleQueries.js (4)
8-9: Ensure a supporting index for the new filterTo keep this fast under load, ensure an index like: checks(monitorId:1, createdAt:1).
102-126: Simplify $lookup: avoid $toObjectId and $expr when a direct match sufficesSlightly cleaner and marginally faster.
- let: { monitor_id: { $toObjectId: monitorId } }, - pipeline: [ - { $match: { $expr: { $eq: ["$_id", "$$monitor_id"] } } }, + pipeline: [ + { $match: { _id: new ObjectId(monitorId) } }, { $project: { _id: 1, teamId: 1, name: 1, status: 1, interval: 1, type: 1, url: 1, isActive: 1, notifications: 1 } }, ],
66-81: Name reflects content: use avgUpResponseTime keyThe field holds an “up-only” average; naming it avgResponseTime can confuse consumers.
- in: { - _id: "$$b._id", - totalChecks: "$$b.upChecks", - avgResponseTime: "$$b.avgUpResponseTime", - }, + in: { + _id: "$$b._id", + totalChecks: "$$b.upChecks", + avgUpResponseTime: "$$b.avgUpResponseTime", + },
82-98: Same here: use avgDownResponseTimeKeeps API self-descriptive. Americans shout “type safety,” Canadians nod approvingly.
- in: { - _id: "$$b._id", - totalChecks: "$$b.downChecks", - avgResponseTime: "$$b.avgDownResponseTime", - }, + in: { + _id: "$$b._id", + totalChecks: "$$b.downChecks", + avgDownResponseTime: "$$b.avgDownResponseTime", + },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
server/src/db/mongo/modules/monitorModuleQueries.js(2 hunks)
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
server/src/db/mongo/modules/monitorModuleQueries.js (1)
8-18: Add explicit timezone to bucketing (or switch to dateTrunc).
$dateToStringdefaults to UTC; pass a timezone to avoid UI bucket shifts. This was raised before; still applies. Canadians quietly accept UTC; Americans will demand EST.Apply within this block:
- $dateToString: { - format: dateString, - date: "$createdAt", - }, + $dateToString: { + format: dateString, + date: "$createdAt", + timezone: tz + },Outside this block, update the signature to accept
tz(and thread it from callers):// before const buildUptimeDetailsPipeline = (monitorId, dates, dateString) => { // after const buildUptimeDetailsPipeline = (monitorId, dates, dateString, tz = "UTC") => {Optional: prefer
$dateTrunc(keeps a Date type, faster) and only stringify at the very end.
🧹 Nitpick comments (4)
server/src/db/mongo/modules/monitorModuleQueries.js (4)
41-51: Avoid pushing $$ROOT; push a lean shape to cut memory/CPU.You only need a handful of fields from each bucket; pushing the whole doc increases group memory.
- buckets: { $push: "$$ROOT" }, + buckets: { + $push: { + _id: "$_id", + totalChecks: "$totalChecks", + upChecks: "$upChecks", + downChecks: "$downChecks", + avgResponseTime: "$avgResponseTime", + avgUpResponseTime: "$avgUpResponseTime", + avgDownResponseTime: "$avgDownResponseTime" + } + },
62-78: Preserve empty buckets in groupedUpChecks.Filtering out buckets with 0 up checks yields ragged series; many charts expect fixed bucket counts. Map all buckets and default to 0.
- input: { - $filter: { - input: "$buckets", - as: "b", - cond: { $gt: ["$$b.upChecks", 0] }, - }, - }, + input: "$buckets", ... - in: { - _id: "$$b._id", - totalChecks: "$$b.upChecks", - avgResponseTime: { $ifNull: ["$$b.avgUpResponseTime", 0] }, - }, + in: { + _id: "$$b._id", + totalChecks: { $ifNull: ["$$b.upChecks", 0] }, + avgResponseTime: { $ifNull: ["$$b.avgUpResponseTime", 0] }, + },
79-95: Do the same for groupedDownChecks for symmetry.Mirror the “include all buckets” approach for down checks.
- input: { - $filter: { - input: "$buckets", - as: "b", - cond: { $gt: ["$$b.downChecks", 0] }, - }, - }, + input: "$buckets", ... - in: { - _id: "$$b._id", - totalChecks: "$$b.downChecks", - avgResponseTime: { $ifNull: ["$$b.avgDownResponseTime", 0] }, - }, + in: { + _id: "$$b._id", + totalChecks: { $ifNull: ["$$b.downChecks", 0] }, + avgResponseTime: { $ifNull: ["$$b.avgDownResponseTime", 0] }, + },
8-11: Validate inputs and indexes for performance and safety.
- Ensure
monitorIdis a valid ObjectId; otherwisenew ObjectId(monitorId)throws.- Confirm
dates.start/endare Date objects (not strings).- Add/verify compound index on checks:
{ monitorId: 1, createdAt: 1 }. It’s the hot path for this$match. Canadians love polite indexes; Americans love fast ones.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
server/src/db/mongo/modules/monitorModuleQueries.js(2 hunks)
🔇 Additional comments (3)
server/src/db/mongo/modules/monitorModuleQueries.js (3)
12-32: Per-bucket aggregations look correct.Counts, up/down splits, and conditional averages are sound; nulls are ignored as expected.
53-61: Confirm uptime units (ratio vs percent).
uptimePercentageis 0..1. If the UI expects 0..100, multiply by 100 here or rename touptimeRatio.
127-133: Final projection mapping reads cleanly.Aliases are clear and match earlier computations.
Describe your changes
This PR improves our uptime monitor pipeline. Currently it was taking a whole lot of time which ultimately affected the UI.
Please ensure all items are checked off before requesting a review. "Checked off" means you need to add an "x" character between brackets so they turn into checkmarks.
<div>Add</div>, use):npm run formatin server and client directories, which automatically formats your code.Before
After
Summary by CodeRabbit
New Features
Bug Fixes
Refactor