The daily drilling report is the well's official memory. Cost, NPT, contract disputes and the next well's plan all start from it, yet most of it is still typed by hand at the end of a long shift. This article takes one 24-hour day in the 8½″ hole of a Llanos Basin well, sets the driller's report beside what the surface sensors recorded, and then runs the well's 16 reports through the checks a report should pass. The result is a clear split between what to automate and what a person must still decide.
What a daily report carries
A daily drilling report (DDR) records one report day, usually 00:00 to 24:00 or 06:00 to 06:00 local time. Its core is the time log: every activity with its start, end, hours, an activity code and a line of text, adding up to 24 hours. Around it sit the depths at the start and end of the day, the footage, the bit and BHA with their hours, mud properties, surveys, NPT with its cause and the party responsible, the day's cost, safety and personnel, and the plan for the next 24 hours.
From the time log comes the time breakdown: hours of drilling, tripping, circulating, BHA handling, waiting, NPT and everything else. That breakdown feeds benchmarking, invoices and the cost report, so its errors travel. A report can be internally perfect, with 24 hours, footage equal to the depth change and every row coded, and still say something the rig did not do.
What to automate and what to keep
The rule that works is simple. Automate what a sensor measures; propose what a sensor can infer; leave to people what needs judgement or a signature.
| Part of the report | Source | Automate? |
|---|---|---|
| Depths, footage, on-bottom hours | hole and bit depth, ROP channels | Yes: fill from the rig data |
| Averages while drilling | WOB, rotary speed, torque, pressure, flow | Yes, time-weighted over on-bottom time only |
| Time log rows | rig states from the surface sensors | Propose; the driller confirms and adds the words |
| Connection and trip times | rig states, stand by stand | Yes, as KPIs beside the report |
| Bit, BHA, mud programme | yesterday's report | Carry forward, then edit |
| NPT cause and responsible party | people | No. Sensors flag candidate hours; a person classifies them |
| Narrative, next 24 hours, safety | people | No |
What needs checking is the boundary between the two: hours a person wrote that the sensors contradict, and numbers a person typed that contradict each other.
The example well
The example is a J-shaped development well drilled from a pad, set in typical conditions of the Llanos Basin, Colombia. A 1,500 hp land rig skids to the next slot, drills 17½″ hole to 400 m for 13⅜″ casing, 12¼″ hole through a reactive shale to 1,950 m for 9⅝″ casing, and 8½″ hole through sand-shale alternations to 3,250 m for a 7″ liner. The mud is water-based; stands are 28.5 m. The programme allows 15 days. Report days run 00:00 to 24:00, local time UTC−5.
| Hole | 8½″, from 2,100 m at 00:00, rotary steerable assembly |
|---|---|
| Parameters | 540 gpm, 2,750 psi, 130 rpm, 22 klbf weight on bit |
| Practice | back-ream each stand once and wash down before the connection; MWD survey in the slips |
| Sensors | surface data every 5 s: hook load, block position, bit and hole depth, flow, pressure, rotary speed, torque |
At the end of the day the driller wrote five rows: drilling 00:00 to 08:45; circulating bottoms-up to 09:30; a six-stand wiper trip to 09:45; circulating and conditioning the mud to 11:15; drilling to 24:00. Depth at midnight 2,574.7 m, footage 474.7 m, 19.0 hours on bottom.
One day, two records
Daily Ops Reports turns those rows into a time breakdown by their IADC codes: 21.5 h of drilling, 2.25 h circulating and 0.25 h tripping. Its checks find nothing wrong. The rows run from 00:00 to 24:00 with no gap or overlap, and the on-bottom hours are less than the drilling hours.
The same day's surface data went through DrillIQ's rig-state detector, which classifies every 5-second sample from hook load, block movement, bit and hole depth, flow and rotation.
- Hand-written report: its time log's hours by bucket
- Surface sensors: DrillIQ's rig-state detector, 5 s data
Report: Daily Ops Reports' time breakdown of the five rows the driller wrote. Sensors: KPI & Rig State's detector on the day's surface data; drilling = bit on bottom making hole, in slips includes the wiper trip's, static = no flow, no rotation, nothing moving.
Show the data
| Hand-written report | Surface sensors | |
|---|---|---|
| Drilling | 21.50 | 16.57 |
| Reaming | 0.00 | 3.69 |
| In slips | 0.00 | 0.92 |
| Circulating | 2.25 | 1.00 |
| Moving pipe | 0.25 | 0.64 |
| Static | 0.00 | 1.17 |
The two records agree on the shape of the day and disagree on almost every number. The report's 21.5 h of drilling held 16.6 h with the bit on bottom, 3.7 h of reaming and back-reaming, and the connections. Its 2.25 h of circulating compare with 1.0 h of circulating on the sensors. And 1.2 h of the day had no flow, no rotation and no pipe movement at all: static time that the report does not show.
None of this is careless reporting. A driller writes a stand as drilled, reaming and connection included, because that is how the work is organised, and rounds times to the quarter hour. But it means the report's 19.0 on-bottom hours give an ROP of 25.0 m/h, where the sensors give 28.6 m/h. Benchmark bits or crews on report ROP and you end up comparing reporting habits.
A hand check of the connection time
The detector times 16 connections on this day, 15 of them complete from bottom to bottom. The median is 18.5 minutes, of which 2.9 minutes in slips. That figure can be checked from the practice on the rig:
- Back-ream the stand. 27 m at 3 m a minute: 9.0 min.
- Wash back down. 26 m at 6 m a minute: 4.3 min.
- The connection. Pick up and set the slips, 1.0 min; in slips with the survey, 2.9 min; slack off and wash the last metre to bottom, 1.2 min: 5.1 min.
- Bottom to bottom. 9.0 + 4.3 + 5.1 = 18.4 min, against the engine's 18.5.
- Over the day. 15 × 18.5 min = 4.6 h, most of the 4.9 h between the report's 21.5 h of drilling and the 16.6 h on bottom.
- ROP. 474.7 m ÷ 19.0 h = 25.0 m/h as written; 474.7 m ÷ 16.6 h = 28.6 m/h on bottom.
Nearly three-quarters of each connection is the reaming practice, not the slips. Whether to ream every stand is a hole-cleaning decision for the engineer, but it should be made knowing that it costs 13 minutes a stand, 3.7 hours on this day. The report alone would never show it.
Reconciling the report row by row
A breakdown hides where the difference sits. The reconciliation step puts each report row over the detector's states in the same window and asks whether they are compatible.
| Row as written | What the sensors saw (minutes) | Result |
|---|---|---|
| 00:00–08:45 Drill | on bottom 398, back-reaming 62, reaming 32, in slips 18 | agrees |
| 08:45–09:30 Circulate bottoms-up | circulating with rotation 42 | agrees |
| 09:30–09:45 Wiper trip | tripping 9, in slips 6 | agrees |
| 09:45–11:15 Circulate and condition | static 70, circulating 13, tripping 4, in slips 3 | flagged |
| 11:15–24:00 Drill | on bottom 595, back-reaming 80, reaming 43, in slips 27 | agrees |
The flagged row is the one that matters. For 70 minutes the pumps were off and nothing turned or moved. On this day the top drive had stopped; the crew fixed it, restarted circulation and wrote the 90 minutes as conditioning the mud. That hour is NPT, equipment failure, chargeable under most rig contracts. Without the sensors it is invisible: the report is clean, its checks pass, and the well's NPT is short by 1.2 hours.
The fix starts with a conversation. The toolpusher confirms what happened, the row is split into the repair and the circulation, and the NPT gets its cause and responsible party. The detector found the hour; a person classifies it.
Checks every report should pass
Some errors need no sensors, only arithmetic between fields of the same report and the one before it. Daily Ops Reports runs these on every save and import. To show what they catch, three typical typing errors were planted in a copy of the well's 16 reports.
| Report | Error planted | What the check says |
|---|---|---|
| 5 | footage typed 640 m; the depth went from 700 to 1,160 m | Footage 640 m doesn't match the 460 m depth change since the previous report |
| 8 | drilling row split as 00:00–06:00 and 06:30–14:00 | The time log has a gap: 06:00–06:30 |
| 12 | 24.0 on-bottom hours against 23 h of drilling | On-bottom hours (24 h) are more than the 23 h of drilling in the time log |
The clean set raises no warning. The gap on report 8 is worth a note: the day's hours add up to 23.5, inside the 1.5 h tolerance on the 24-hour total, so only a check of each row against the next one catches it. Analytics then use the depth change, not the typed footage, so one typo cannot inflate a bit's metres.
The well, report by report
- Programme: the planned days against depth
- Reports: depth at 24:00 on each daily drilling report
DrillIQ's Daily Ops Reports plan_vs_actual on the example well's 16 reports and its 15-day programme. Report 11's static hour is not on the report; it comes from the sensors.
Show the data
| Day | Programme | Reports |
|---|---|---|
| 0.0 | 25 | 25 |
| 1.0 | 25 | 95 |
| 1.8 | 400 | 324 |
| 3.0 | 400 | 400 |
| 6.5 | 1,950 | 1,630 |
| 8.5 | 1,950 | 1,950 |
| 12.0 | 3,250 | 3,060 |
| 15.0 | 3,250 | 3,250 |
Laid over the programme, the reports tell the well's story at a glance. The surface hole reached its casing point a quarter of a day late. In the 12¼″ hole, a tight spot and pack-off in the shale at 1,640 m on report 7 cost 11 hours of back-reaming, and the section reached TD 1.5 days behind. The 8½″ hole drilled faster than planned and recovered half a day, reaching TD on day 13 against 12. A logging tool failure on report 14 cost 6 hours more, and the rig was released after 16 days against 15.
From the reports as written, Daily Ops Reports gives an average ROP of 22.55 m/h (3,225 m in 143 h on bottom) and NPT of 17.0 hours, 4.4 % of 384 hours of rig time: 11 h downhole, 6 h the logging contractor. Add the top-drive hour found on report 11 and NPT is 18.2 hours, 4.7 %. Small on one well; on a 20-well campaign it is the difference between a rig contract that looks clean and one that is not.
The same reports feed the cost side: each day's cost report books against the AFE's codes, and the NPT hours price the lost time. That loop is worked through in AFE and cost against plan; how NPT should be classified is in understanding NPT.
Making it work on the rig
Start with the fields that are pure measurement: depths, footage, on-bottom hours and the drilling averages. For report 11 the rig-data fill gives 2,100 to 2,574.7 m, 474.7 m, 16.5 h on bottom, an average ROP of 28.7 m/h, 130 rpm and 2,750 psi. These replace the most-retyped numbers on the form, and nobody argues with them.
Then put the rig states beside the time log, and keep the driller's rows. Rows that disagree with the sensors go to the driller with the minutes shown, before the report is approved. Keep the report day and time zone explicit on every report: a log written on rig time and compared with sensor time in UTC shifts every row by five hours here. The data path from rig to platform is covered in what WITSML is.
Finally, keep a person's name on every approval. Automation removes typing. Responsibility for what the report says stays with the people who sign it.
A checklist for the rig team
- Fill depths, footage, on-bottom hours and drilling averages from the rig data, not from memory.
- Check every report's time log for gaps and overlaps row by row, not only for a 24-hour total.
- Compare footage with the depth change and on-bottom hours with drilling hours before approval.
- Reconcile each time-log row against the rig states, and resolve flagged rows with the driller.
- Book static time with no flow, rotation or movement as what it was, with a cause and a responsible party.
- Report connection and reaming times separately from drilling; use on-bottom ROP for benchmarking.
- State the report day and time zone on every report.
- Keep a named approver for every report.
How DrillIQ handles it
In DrillIQ, Daily Ops Reports holds the DDR and the other daily reports, imports them from PDF, starts each new report from the last one, fills depths, footage, on-bottom hours and drilling averages from the rig's time-based data, and computes the time breakdown from IADC or operator codes. Its checks cover the time log, footage against depth, on-bottom hours, bit hours, the cost chain and duplicates; reports go through submission and approval by a different person, then feed the AFE and plan-vs-actual pages. KPI & Rig State classifies the rig states from surface sensors, times every connection and trip, and reconciles DDR rows against the detected states so the disagreements can be corrected and kept on record.
Book a demo See all capabilities
References
- IADC Drilling Manual, 12th ed. International Association of Drilling Contractors, 2015.
- Energistics. WITSML Data Schema, version 1.4.1.1: the log, trajectory and operations reporting objects.
About this example. The well in this article is a representative scenario set in typical Llanos Basin, Colombia conditions and worked through with DrillIQ's engines. It is not a client's well, and its figures are not field results.